I have Visual Studio 2008 Database Edition, and everything worked great until the first time I tried to load a .dbproj file. These database project files work for the other developers I work with, but when I try to open it, I just get an error message "Object reference ot set to an instance of an object."
It's probably the same problem this guy is having, although he didn't do a good job of describing it and has no solution.
Every other kind of project file loads and builds and runs normally. dbproj files all generate this cryptic error. I just tried a fresh removal and reinstall of Visual Studio 2008 DE to no avail. Could this have something to do with my SQL 2005 installation? (This also works normally through SQL Server Management Studio.)
**
UPDATE
**
Probably even more importantly, this same error occurs when I try to make a new dbproj file. Every other type of project can be created no problem.
You need to tell Visual Studio the correct instance of SQL Server to use for validation.
Tools>Options>DatabaseTools
Change the settings in "Data Connections" and "Design-time Validation Database" to reflect the correct instance.
After many failed re-configurations and re-installations, a member of my team discovered the problem!
Under Tools > Options > Database Tools > Design-time Validation Database, there is an option to set your SQL Server Instance Name. Visual Studio automatically picks this when it's installed.
The key is that Visual Studio doesn't necessarily pick the right one. I happen to have 3 SQL server instances on my machine. SQLEXPRESS (a 2005 instance that Visual Studio installed alongside itself), SQLEXPRESS2005, a 2005 instance I installed, and SQLEXPRESS2008, which I also installed.
Visual Studio had configured itself to connect to the SQLEXPRESS2008 instance, even though it only supports SQL2005 dbproj files by default. By opening this dialogue, and updating the server instance name, the error no longer appeared and I was able to open dbproj files:
Related
I have seen other posts about this topic where some of the suggestions lead people to check the ProtectionLevel to DontSaveSensitive. I have made sure that is set to DontSaveSenistive, as well as I have checked permissions and made sure where the files/dtsx files are getting called from have ample permissions set for the service account which owns the SQL Agent.
The odd thing is this process was working fine until i went into one of the previous dtsx files and had to update a datatype precision to go from a limit of 1 character to 30 characters. That was literally the only change made to the process, but now I am getting this error. I have gotten this error before, which is when I was set on the path to checking protection level and permissions/ownership. For some reason it went away and began working when i made those changes. None of that stuff (permissions/ownership) is incorrect this time around yet I am getting that same error.
Another weird thing about the process is that it is only the last step which is failing (the FTP step.) When I try to go in and execute the psftp.exe and put in the command which is being passed normally through SSIS execute process task step, the psftp.exe is telling me that the port number is incorrect..yet when I test connection on the connection manager inside VS with the exact same port, it says connection successful.
This error is vague and confusing!
I would love some guidance on some more things to try.
thank you !
SSIS tooling and version
SQL Server 2008 and 2008 R2 can only be edited using Visual Studio 2008 which has the Business Intelligence Design Studio templates installed. Those can only be acquired by having the physical SQL Server iso handy. Developer edition will work, but you need some form of licensed media to get BIDS working.
Visual Studio 2013 is going to attempt to upgrade 2008/R2 to the internals for a SQL Server 2012 installation. There is no going backwards/downgrading once this is done.
Any tooling (dtexec, dtutil, etc) you use must be from the same version otherwise, the first thing the binaries do is update the package to match that version. For execution (dtexec), each time you run a package, there is a delay as the original is upgraded in memory to match and then execution begins (assuming all goes well). It sounds like it's not based on
The package failed to load due to error 0xC0010014...
For deployment (dtutil), you only pay the price of upgrading once and then it's upgraded forever. Which probably isn't what you wanted. Be aware that tools like Visual Studio and SSMS "know" which version of tooling they are associated with so deploying from SSMS 2016 can result in the binaries for SQL Server 2016 SSIS upgrading your 2008 package to 2016 format and then attempting to deploy the now upgraded bits to your 2008 box. It's all very frustrating and not intuitive.
From your comment "In the 2008 version, the play button is greyed out..." That indicates you have opened a File in Visual Studio that is an SSIS package. Visual Studio will open it and paint all the icons on there but it can't actually run a package unless you have an Integration Services project open (and have the BI templates installed).
Assuming you have source control, you can rollback the change that broke everything and try to edit the package properly.
Execute process task
You have an Execute Process Task that is invoking psftp.exe and it's generating a 1 versus a 0. Is that bad? Based on previous workings with SFTP clients, they're rather picky so running it as me on production would fail since I didn't have whatever bits associated to my domain account but the service account had all the right things in their profile and it would run just fine - same machine, same package, just different user.
I recently used the repair function in my Visual Studio Installer that I thought could fix the error message: Microsoft data transformation services designer package did not load correctly. However it turns out there is a new error message when I wanted to load my previous project: The "Package" package did not load correctly.
If I continue the loading, I will receive some other warning message in the solution Explorer saying my project is "incompatible" and "the application is not installed":
I initially also tried to follow some online solution and tried to repair Microsoft SQL Server Data Tools in control panel. It doesn't allow me to repair and says Setup Failed almost immediately after I click on the repair button.
Initially I was trying to add an WCF extenion in Visual Studio but seemed failed and threw the first error message to me. Then when I try to repair, the first error message is gone and I was given the second error message. Now I stuck in there.
I have also checked if SSDT is included in the installer and New project types:
It seems the SSDT is selected in the Visual Studio Installer and all my current project types are listed in the screenshot as well (previously I was able to see Integration services as well but now after the repair I can't).
I'm using Visual Studio Enterprise 2017 on a test server that a few people have access to (I've also tried to restart the Visual Studio and the server but it didn't help).
Hope I can get some suggestions here, really appreciated.
I'm migrating a solution which contains some C# projects from Visual Studio 2008 to VS2013. The migration went fine, with a few adjustments, but there's also a .dbp project (database project, from VS2008), which refuses to migrate / load in VS2013.
The closest project type I found in this newer version is "SQL Server Database Project", I've created one and added my existing .sql script files, but this project type (.sqlproj) appears to be something different. For example, VS 2008's "database project" does not build. Also, I had a hard time trying to add a reference to my existing SQL database running under SQLExpress.
I've also set BuildAction = None to all my script files, and now I can open each of them manually and execute. But still, I'd like to select multiple files and execute them all at once. Seems I'm missing something.
So, is there a way to accomplish that?
I suggest you look at the following article to convert the dbp to dbproj: MSDN
And after that look at the following link to convert dbproj to sqlproj: Tentacle Software Blog
I'm running some load tests using Visual Studio 2010. I haven't been able to figure out how to set where the test results are saved, and it seems that I have no test results to browse once the test runs.
I have the general idea that you're supposed to supply a SQL connection string specifying a SQL server with some tables set up on it.
Where do I set the connection string for local test runs? Is it possible to configure VS2k10 to save my test results to a file locally?
Please note that local SQL databases such as SQL Express are specifically forbidden in my environment.
If you find yourself in a situation where you didn't setup the database to store the test results from the VS 2010 Load Tester, the following will help.
The default install of VS 2010, won't have the Microsoft Visual Studio Test Controller 2010 tool.
To create the necessary tables to store the test results, all you need to do is run the loadtestresultsrepository.sql script against your database.
You'll find this script at:
x86 - C:\Program Files\Microsoft Visual Studio 10\Common7\IDE
x64 - C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
Taken from:
MSDN: How to: Create a Load Test Results Repository Using SQL
Visual Studio strictly requires SQL Server for the load test store. If you don't have a SQL Server database, you cannot save test run data. All you can do is browse the result immediately after a test run, and perhaps copy-and-paste the test details into Excel. After you close the result, it's gone for good.
However, the database does not have to be on your local machine. Is there any chance you can get access to SQL Server somewhere else on your network?
You have to run "Microsoft Visual Studio Test Controller 2010 Configuration Tool" (found in Visual Studio start menu folder) to configure the database before use.
Setting the connection string is done in Test (menu) > Manage Test Controllers. This dialog allows you to select the Controller (or 'Local - No controller' for local tests) and also allows you to set the connection string to the load test results store.
I have been using a database project in visual studio 2010 to create a database. Visual Studio makes this process really easy to deploy the database and deploy updates. The issue I have is how I can get visual studio to create a script that will build the database that I can use on a QA or production system.
I thought that building the project would create a SQL file that did this but this does not seem to be true. Can someone please advise on how I can do this or what simple step I am clearly missing.
As strange as it may sound, Visual Studio does not create a SQL file to deploy your database when you perform a Build.
Instead, this occurs at Deploy time. The reason behind this lies in the way that Visual Studio makes changes to the database that you're deploying to: in order to change your database, it must first compare the project model (as defined in the files contained within the .dbproj) with that of the existing database schema to determine what changes you have made since the database was last deployed.
You then have the choice of manually executing the SQL script produced using the SQLCMD command-line utility (or through SSMS in SQLCMD mode), or alternately you can configure your Visual Studio Database Project to execute the script if you specify the following Deploy Action in project settings:
Generate a deploy script (.sql) and deploy to the database
Note that you will need to provide a connection string in project settings so VS knows where to deploy to.
When you get to the stage where you want to deploy to a QA or PROD environment, you have a couple of options:
Deploy directly within Visual Studio. In addition to the standard Debug and Release configurations that you get when you first create your Database Project, you can also create your own configurations which you could use to deploy to your QA and PROD environments (i.e. potentially with a different connection string/target database name).
Deploy from a Build Server. Install Visual Studio on a separate machine and call MsBuild against your .dbproj/.sln file with the Build and Deploy targets specified along with the appropriate connection properties.
Doug Rathbone has written a great blog post on subject if you want to learn more:
http://www.diaryofaninja.com/blog/2011/06/23/compare-amp-update-database-schemas-right-within-your-ide--part-2-automation-with-teamcity