Vs2022, I have a database project. Within that project are some views and functions which refer to a system database. So I have added those system database references, both Master and MSDB to the project. The references work, all is good.
I close the solution and reopen it, and now the project shows two references to each database, and a bunch of script errors because an unresolved reference exists:
So the fix is again to remove these 4 references, add the database reference back to master and msdb, and then all is good, until I reopen the solution again!
One side note, this solution was originally created in VS2019. Also, this happens on 2 separate machines. I'm running VS 17.3.3 64-bit.
For anyone facing the same problem, VS 2022 adds two references to the DBs, one from VS extensions folder and the other one from SQL Server folder, its definitely a bug and happens often when updating VS 2022.
However, the solution is to delete the second one from the project references (SQL Folder Reference) and then you need to click on the project and explicitly save it by using Ctrl+S, otherwise, the change will not be saved and whenever you close and open the solution, the project will show invalid references.
Related
I am using VS 2013 for database project. I want to drop ojected from target db which are not in db project including table and SP's. I have checked property "DROP objects in target but not in project" but it doesn't work. I still see table in target which is not part of db solution. I do not see any warnings either and btw table is empty so it should be dropped without warnings anyway. I have used same option in older version of Visual studio and it worked.
Any suggestions?
I know this is a long time coming to answer the question, but this is how I resolved the problem. I simply opened the SQL File TableName.sql
Ctrl+a (aka select all)
Compare
It will show the file with an action to delete in the compare
Update
Delete the file from Visual Studio 2013 project
Hopefully this will make some sense ..
We have a bunch of database projects that we use to maintain schema and generate upgrade scripts. To generate the upgrade scripts, we use an automated build engine which uses SqlPackage.exe to compare the database project with a "schema template", which is a copy of the live database, but with no data.
One of these databases has references to three of the other database projects.
Recently, we've found that when the upgrade script is generated for this database project, it includes refactoring SQL for tables that are in one of the references project, and not in the project in question.
So the upgrade script includes two lots of SQL:
Print statements at the start saying that a schema object will not be renamed.
A bunch of insert statements into __RefactorLog.
The problem is twofold:
These refactors should not be included in this upgrade script; they belong to one of the referenced database project - they have nothing to do with this one.
Because this database does not require refactoring, it has no table called __RefactorLog because they upgrade script doesn't need to create it. This causes a build failure.
I've looked through the database project settings and can't see any reason why the refactoring from a referenced database project would be included in referring project.
Any ideas?
UPDATE - The missing __RefactorLog table was a red herring. For some reason it was included in the schema template but was not in the live database, so SqlPackage assumed that it did not need to create it. However, I'd still love to know why all of the refactoring from a referenced database project is included in the problematic one.
This is a bug in SSDT - there's a Connect bug tracking this. Note that for "Same Database" references the refactorlog is expected to be included. This is because all the objects will be pushed to one database. The bug is that the refactorlog for "Different Database" references is incorrectly included, which I'm guessing is what you're running into.
I need to include a Stored Procedure in Visual Studio 2013 which references another Database which is not part of the solution. I only refer to a very small portion of the external database which is itself big and complicated.
I know I need to add a reference to it so that I don't get warnings when referring to objects within the external database from within the Stored Procedure.
Adding that Database to a this or another Solution is not an option as its not part of our solution and importing that creates a whole variety of other issues.
I can see in older versions of Visual Studio that I need to create a schema file using VSDBCMD but this has been replaced by SQLPackage, but I can't see how to access that and whether it will need the external database anyway.
I've been going round in circles on this, so some pointers would be warmly welcomed.
I realize I am late to the party on this but perhaps it will still be useful to someone: You don't mention if this is a c# project or a database project.
I'll assume database as I not sure how you'd get errors otherwise on the internals of an SP.
The only way I know of to remove errors on cross-database references is to add the other database as a project in the database solution, add a database reference to the project with the sp, and then instead of using Database.schema.table syntax in the sp change it (in the database project) to [$(database)].schema.table
Alternately, a DACPAC can be created on the referenced database and used instead of referencing the database in an added project.
I'm new to this stuff myself, but I work with a lot of database cross-references in my sps so I am working through how to address this in database projects
I have a SQL Server CLR trigger project that was created in VS2008. Opening the project in VS2012 does not present any problem, but on build of the solution, I get SQL71501 errors, with Trigger: [...] has an unresolved reference to object [...].
Based on my reading, this is due to a missing database reference in the project. When I try to add a database reference, I get the Add Database Reference dialog that gives me three options:
Database projects in the current solution ** this option is grayed out/disabled
System database (only shows system DBs)
Data-tier Application (.dacpac) ** there are no options to select as this was not how I created the project.
Further reading suggested that the reason there are no database projects to select for the first option, is because no Data Connections have been added via the Server Explorer. In my case there are certainly Data Connections present, and while my project is open, I can quite happily browse the database, look at data etc.
I thought it might have something to do with the Target Framework, so I have tried targeting 3.5 and even 2, but the same problem occurs.
I feel like I'm missing something fundamental, but just can't quite work it out. Any help would be GREATLY appreciated.
I've seen this dialog not enable the 'OK' button because the Database Variable that it defaults is invalid (in my case it had a '.' in it).
The clue to this being the error is that the text in the 'Example Usage' field contains the error message - it's just hard to see as it's dark grey on light grey.
Editing the Database Variable name fixes this.
I found a workarroud for this, isn't optimal but at least it works:
try this
- open sql server object explorer
- create a new connection to your server
- right click on the database and select create new the project...
- the wizard will create the project with all the references and connection string attached to it.
cheers!
I changed my answer
The problem is you cannot assume an insert is a single row and you can really only reference the primary key as a single value inside the trigger
I'm working on a project which relies on the presence of a number of tables, views and stored procedures. Until now I have built these all in SQL Server Management Studio.
Now I would like to continue to work on them inside of Visual Studio. This will provide the benefit of version control (along with a number of other benefits hopefully).
I have added a new project to my solution and started working on one of the views. When I tried to build the solution it failed as the new project didn't have a server/database associated: Error 1 SQL03006: View: [dbo].[vw_Test2] has an unresolved reference to object [EV870_ACCT_MASTER].
I was able to overcome this by
-creating a dbschema dump using vsdbcmd.exe
-adding the dbschema dump as a reference to my database project
Is this the correct approach?
Now i can see the schema (tables, views, sprocs etc) in the Schema view (I had to enable display of "external elements") and the error message has gone away. Note: I had to reference like: [$(SQLDatabase)].[dbo].[EV870_ACCT_MASTER]
Now I want to know how I can work with these objects that i've scripted. I don't know how to use the new tables, views, sprocs etc (I want to use LINQ). Do i have to run the scripts first? How then if they are "CREATE OBJECT" scripts, will they run in future (presumably they'd fail as the object already exists in the database). Will my project/solution know which objects need updating and update them?
Ultimately want to take it a lot further- my aim is that the solution will be portable and a the server/database will be configurables. Then my tables, views and stored procedures will be created or amended if they don't exist or are out of date. Is this possible?
When I then start working with the views etc using LINQ I want those server/database references to remain dynamic?
I know there are quite a few questions in there but i'm hoping someone will be able to point me in the right direction- there doesn't seem to be much useful documentation online (or that i've stumbled across so far).
Thanks
Lee
Where I work (and the last place I worked) we distribute the sql scripts to create the database along with the app. In sql a version number is stored and when the app is run it checks to see if its version is newer than the number stored in the database. If so then it knows it may need to run some new sql scripts in case there were any schema changes. When this happens, we just run through all the scripts because they are written in a way that running them multiple times won't hurt anything... this way we don't have to worry about tracking which scripts are the new ones. Just check the version number and that's it.
As far as working with this stuff in Visual Studio instead of Management studio, I'm not sure why anyone would want to do that. Depending on what you use for source control you may be able to get hooks for Management Studio, but even if not that doesn't stop you from keeping your sql scripts in source control. And I wouldn't switch from working with my sql files in management studio to visual studio for the benefit of having built in source control any day.