I want to import a database in .bak file to business intelligence in vs2013. But when I click "import from database" in analysis services (new project), I get an empty servers list, and localhost as a placeholder in a text field. Why is that so? How can I solve this?
I installed sql server 2014 and have an instance running.
Related
I would like to create a new installation of TFS 2013 on a new server.
I made my research and learnt that the migration process as it is described on this link below carries some risks:
TFS Migration Manual:
https://msdn.microsoft.com/en-us/library/ms404869.aspx
Risks:
http://blogs.msmvps.com/p3net/2014/04/12/tfs-upgrade-nightmares/
I have a plan to avoid using the TFS Migration manual above, instead; I would instead check all of my projects out (about 20) and then re-create them on the new TFS and check them in again.
However, we have work-items, users, workspaces and other agile information which I have created for my projects, and which I still require to be on the new installation.
I was wondering whether the following works (again without risks and hassle, as time is scarce):
Back up the TFS Databases from the old installation, and restore them into the new installation or simply import the data from old to new using SQL Server's Data Import Tool.
I am particularly referring to these databases, which TFS has:
Tfs_Configuration; Tfs_DefaultCollection; Tfs_Warehouse.
I found these databases on the SQL Server instance which TFS uses.
Also, this approach works easier without having to obstruct the team, as the Data Base Resotation can occur after hours..
Now, will this plan work?
No, your plan will not work and will leave your TFS in an unsupported state.
You need to follow a combination of the Upgrade and "changing environment" workflow.
1) Restore all TFS databases (tfs_*) to tye new environment
2) Install TFS 2015
3) Configure and select Upgrade Wizard - when running make sure you have all the new server names
4) (optional) ChangeServerID - if this is a practice run you should then immediately:
4.1) I unconfigure the application tier with "tfsconfig exe setup /uninstall:all"
4.2) run the ChangeServerID command
4.3) reconfigure tfs and run the "app tier only" wizard
Simples....
Note: You need to change the server ID if this is a test/practice instance as each server gets a unique ID. When clients first connect to the new server they will "upgrade/migrate" the users data across. You don't want that happening for a trial...so change the ID...
WARNING: If you manipulate the data in the TFS server in any way that is not done by the TFS Product Team tools you will turn your instance to crap. Do not ever edit, or cause to edit, the data in the operational store.
I have a quarterly update package that I run from the backend of our system that uses an Excel (2007 format) document as a data source. The package stages the data from the Excel document to a table within the database, where it is processed and loaded in the production system.
Today, I received the Q2 update for April 2015, and attempted to run the new file into the staging system through Visual Studio as I have in the past. But for some reason today, VS / SSIS appears to be stuck "Validating Excel Source". I've let it sit for up to 10 minutes, before having to kill my Visual Studio instance through Task Manager.
The source document is small and relatively uncomplicated on 6 columns and less that 300 Kb in size, so I can't understand the validation issue all of a sudden. It appears to be the same excel version and format as my previous runs.
This package has been untouched for the better part of year, only having to change a series of parameters for each quarterly run.
I've deleted the connection managers and excel components from the package and recreated them but still appear to have the same issue. I've also recreated the source document.
I attempted tp disabled the DelayValidation and ValidateExternalMetaData properties, in hopes that it might give me a meaningful error dialogue, but have yet to get past the "Validating Excel Source" message.
Any input would be appreciated, Thank you.
I appear to have found a resolution to the issue.
It appears that a recent update to my installed Office suite altered the driver for Excel on my machine.
The following articles helped me resolve the issue, but as it turned out I needed to reinstall the Office 2007 System Driver: Data Connectivity Components...(linked in the 2nd article)
Once installed I was able to reopen my solution and view the Excel document.
Thank you for the assistance.
Using Excel 2012 file in Excel Connection Manager
How to fix errors: "the 'microsoft.ace.oledb.12.0' provider is not registered on the local machine"
Remove the excel file that the connection manager is looking for from the directory that it is pointing to. Once you do that the Validation of the Excel source should fail when it can not find the file it is looking for. This should allow you to get into the package and set Delay Validation = True in the properties.
The package validates the excel connection manager the same as it would any other OLE DB connection manager. It confirms connection and then runs your statement to validate the return of data. If you take away its source it should flame out quickly.
I have found that background processing on your machine can block this validation or processing of the request the same as a priority query might in SQL. If you machine is in a state with a number of priority tasks running this validation is put on the back burner and can and will take forever. In cases like this the connection used to the source being used to validate with either disconnect or timeout and it is not handled in the UI so it just hangs and locks up.
In Visual Studio 2012 we have new project type called SQL Server Database Project and when compiled will create a .dacpac output file.
A Google for this term will link it with Data-tier Application but I cannot link this name with D A C P A and C?
What does dacpac stand for?
In the article 'It’s Data Tier Application and Data Application Component' from December 23 2009 Microsoft's Buck Woody states DAC stands for:
Data Application Component
And he also talks about the result as a package, so it seems reasonable to surmise:
The PAC part probably refers to package.
This is the relevant quote (relevant part in bold, my emphasis):
OK – In SQL Server 2008 R2 we did “re-use” an acronym or two (DAC and
DTA), but it’s important to remember there are actually two parts to
this new feature. One is the Data Application Component (DAC) and the
other is the Data Tier Application (DTA). The DAC is the file created
for a DTA.
In SQL Server 2008R2 and Visual Studio you’ll find there is a new way
to write and transfer database code. I’ll blog about it more as I
finish my testing, but the process works kind of like this…
You can “birth” a Data Tier Application in two places. You can create
a new project type in Visual Studio where the developer can create the
database structure, put all of the policies that they want to enforce
and so on there. The DBA can also right-click a database and make a
Data Tier Application out of a current structure.
In both cases, something called a DAC – or Data Application Component
– is created. It’s a file with the payload of the the major parts of
the structure of the database and so on. that’s the “package” you use
to transfer the DTA around.
From there, you right-click in the “Data Tier Application” node in SQL
Server Management Studio on another Instance and “Deploy” the Data
Tier Application. It will build the database for you and keep it
together as a DTA. You can make changes in the “originating” system or
code, and then “upgrade” the Data Tier Application.
So there you have it. It’s DTA and DAC – but I think you’ll know the
difference when the time comes to use one…
This InfoWorld article suggests a slight variation on the above, stating that the DACPAC part stands for:
Data-tier Application Component PACkages.
DAC stands for Data-tier Application
PAC stands for package
So to my thoughts, DACPAC stands for Data-tier Application package
First off: read this.
dacpac is a Data-tier application. More concretely, it is the file that gets created when you build a SQL Server Database Project. It contains all of the information necessary to build the db objects specified in your SQL DB project.
I am writing a "framework" of SQL Server (targeting 2008R2 and 2012) stored procedures and common/reference tables. Each SSDT/Date-tier project represents a different component (can be within the same database) within this framework (e.g., MasterDBExtensions project has stored procedure extensions/add ons within the Master Database, SQLServerAgentExtensions (msdb), etc).
I developed a farily strict security model heavily based on Schema, database roles, and certificates.
My issue is how do I "share"/copied these certificates between the active project and the referenced projects so that when I publish the active project to SQL Server the certificates are properly copied, etc. (btw I need to share/copy the certificates for cross-database object access so that I do not need to turn the Trustworthy flag on, Service Broker, and also for linked server access).
Just for clarification I have some TSQL Code that represents what I mean:
use [DatabaseA]
Create Certificate [MyCertFromA] ...
Backup Certificate [MyCertFromA] to File = 'MyCertFromA.cert'
use [DatabaseB]
Create Certificate [MyCertFromA] from File = 'MyCertFromA.cert'
SSDT/Data-tier will NOT allow me to place the Backup and Create/From statement (I get the "This statement is not recognized in this context"). If I move the Backup Certificate to a Pre/Post Script I run into issues with file permisions and other issues (e.g., Certificate NOT found). Besides the Pre/Post scripts do not run if I use the project as a database reference in other projects.
So... What am I doing wrong or does anyone have any suggests around these issues?
Thanks!
Enviroment: SQL Server 2012 (I also target SQL Server 2008R2), MSVS 2010, SqlServer Data Tools Dec. 2012, SQL Sever Data-Tier Application Framework May 2013, C# 4.0
Looks like this has been answered somewhat by CTP4 Certficate issue - sometimes server, sometimes database scoped
I am using mvc3 to develop an database application and followed the Code-First Tutorial using Entity Framework 4 of msdn site....
I followed all the steps but unable to see the sdf file....
I can perform CRUD operations but can not see the physical database file inside the app_data folder
I also did "Show all file" but still it is not shown in my visual studio explorer...even my App_data folder is empty...
Code inside the web.config file:
<add name="Forum1Context"
connectionString="Data Source=|DataDirectory|\Forum.sdf"
providerName="System.Data.SqlServerCe4.0"/>
Please Help me!!
I experienced a similar issue. In my case, the name attribute in the add tag was not the same as the name of the class which inherited from DbContext. When I changed the name attribute to match, then I could see the .sdf file, but rows I had inserted previously into the database were lost.
It could be that the Database considered your SQL Express rather then the connection string. Fire up SQL Management Studio and check your SQL Express server
"Data Source=|DataDirectory|Forum.sdf" means Database file is located at "App_Data" folder.
And if you can even perform CRUD operation, Database file should be already there as "App_Data\Forum.sdf". (Please also verify with window explorer).
On Visual Studio, need to enable "Show All Files" on Solution Explorer to view Database file.
Just wanna point out that SQL Express and SqlServer CE are different. SQL Express will need a memory pipe or TCP connection like any other DB server, and the Sql Server CE will automatically create your DB file if doesn't exist at first runtime.
Could it be that you haven't run our app (and EF4.1 code) hence your .sdf file isn't there yet?
Just remove the backslash \ before Forum. I think that will solve it.