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
Related
I've created an SQL Server Database Project so that I can capture my database schema and add it to source control.
My problem is that the database contains Views which reference external databases. Given the business and project environment, this is an acceptable solution in the short tomedium term.
Sadly, this stops the database project from compiling, (since it don't contain the external database tables).
What are my options for getting around this error? I'm currently storing the schema in a single generated script, which is a pain to update.
Look at creating dacpac files out of the external databases and add them as database references. I did that by using the SQLPackage command line to generate the file, put the files in a "shared" folder (optional, but useful if this pattern persists with other projects), then add a database reference to the project. I recommend removing the variable for the DB name unless it can change in different environments. I blogged a bit about this here:
http://schottsql.blogspot.com/2012/10/ssdt-external-database-references.html
Now if it's a truly breaking change, I've done this through post-deploy scripts. Drop/recreate the view and reapply any permissions necessary. That's not ideal, but it can work.
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'm new to using SQL Server 2008 DB Project's in VS 2010. I found a good intro to setting them up. It's nice how they create Tables, Stored Proc's etc as objects. But is it also a limitation?
I want to use this project to manage 1 stored procedure (for learning). I do not want to import the entire database because 90% of the database is stuff we do not manage.
I created a new project without doing the import process. I then added a new stored procedure. Now I am having difficulty getting the thing to build. I'm getting various errors saying that I have unresolved references to objects.
How can I add a new stored procedure..build it and deploy it to the database? Is it possible with this kind of SQL project or do I need to drop back to the old, simple type of SQL projects that VS 2008 and below used?
Update
According to another post, support for the Database Project type is gone. Support for my situation appears to have been erased.
UPDATE 2 3/21/2012
I installed MSSCCI which allows me to use SSMS directly with TFS 2010. I no longer needed and found the setup process to be unmanageable for a large database SQL 2008 project. Especially when you only manage a small % of the DB.
You can Partition a Database Project by Using Partial Projects. This allows the database project to know the entire schema of the database, at the same time, you need not maintain the entire schema. You can work with the subset of the database that's under active development, for instance (or the subset which is your responsibility), yet the project knows the entire schema. This permits it to create change scripts at deployment time, by comparing the schema in the project with the schema in the target database.
You must import all schema objects referenced by your new stored procedure. But this can become a large task because every referenced object need all it's references too.
More trouble with linked server objects.
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.
I have Visual Studio 2010 Beta 2 and SQL Server 2008 installed. I'm working with a populated database and want to modify various column types. SQL Server Management Studio requires me to drop tables to do this, and get pretty finicky given my moderate level of knowledge of SQL Server.
However, I heard the new database project type supports changing the database schema to the desired format and it will handle creating and running all the scripts to implement the changes.
I've created a VS2010 database project using the existing database as the source, but so far haven't had much luck figuring out the appropriate method to make the changes without getting an error.
As a result, I'm looking for any reference info I can find on using VS2010's capabilities in this area. Any suggestions?
write scripts instead of using the gui. You can use alter table for instance to change a column. Never use a GUI of any kind to create a change to a database table.
Here's a walk through of the new VS2010 "Deploy-SQL" tab in the properties page of web application projects.