We are using Visual studio 2010 and our database scripts are in a database project.
We have two databases DB1 and DB2. DB1 uses DB2.
I created a database project for each of databases and added DB2's .dbschema file as a "Database Reference" to DB1's project.
So my code for my view in DB1 is like
CREATE VIEW dbo.myView
AS
SELECT * FROM [$(DB2Ref)].dbo.SomeTable
GO
Until here all is fine.
But when i make a schema comparison between actual DB1 database and DB1 database project, comparison finds a difference between "myView" in project and "myView" in database.
Is there a way to make schema comparisons igonore these referenced database variables ?
Yo can set the Default for the SQL CMD Variable in the project settings to the actual database name. The schema compare in visual studio will then know that there is no change.
Unfortunately if you compare against different databases with different names, you'll need to change this Default each time to the database you're comparing to.
Setting SQL Cmd variable Default
SQL Schema Compare of View - the top is without the default defined and thus the object is marked as a change, and the bottom with the variable defined and thus marked as no-action
Sorry not enough rep to add images or more than 3 links yet
Related
I have created an Oracle Database Project Version 2 on visual studio 2017 and imported an existing database to the project to obtain the database schema on my project, and I got an SQLfile for such object in my project. The problem is when I'm modifying a table for example and saving the changes on my oracle database project and build it, I get a create script as output instead of an alter script so this script can't be deployed to my database due to "existing object error".
I tried to do it otherwise by proceeding to schema compare option:
I launched the schema comparison by mentionning my oracle database project as source and my database as target
The result of the comparison indicated that there is an non indentical object between the source and the target which was the table (because i added a coloumn to the table)
Again the problem is when I generate the update script it gives a drop/create table script instead of an alter and I can't deploy this script because I will lose data.
Does anyone have any ideas? how can I get the alter script by building the project or launching a schema compare operation?
I've found that comparing two databases DO generate a "somewhat" correct diff script (it may need some manual adjustment). So you can run the SQL file generated by the database project against a different oracle instance, and then compare both.
When using a SQL Server Database Project in Visual Studio, if you have more than 1000 stored procedures in a database, when you import it Visual Studio will split the procedures into separate directories.
When you attempt to sync any new stored procedures into the project following such an import, via the 'Schema Compare' function, Visual Studio forgets this split folder structure and places all new scripts directly into the 'Stored Procedures' folder. This means that new stored procedures which are scripted do not fit into the existing structure, which forces the user to either live with this detached structure or to manually update project references and copy the files back into the initial structure which Visual Studio created.
Steps
Create a new SQL project.
Right click on the project in solution explorer > select 'Import' > 'Database'.
Bind the project to a SQL2008 database which has more than 1000 stored
procedures. Select 1000 for 'Maximum files per folder'.
Allow VS to script out all of the stored procedures. It will automatically
break into batches of 1000 and create a new folder 'Proc1', 'Proc2'
for each batch as necessary.
Open a new comparison by right clicking on the SQL project > select 'Schema Compare'.
Verify the database synced correctly by comparing the SQL project to your
original database. There should be no pending changes.
Create a new stored procedure in the database which was synced.
Run the comparison again, this should now show the new stored procedure
under the 'Add' type.
Click 'Update' and allow VS to create a script for the new procedure.
Instead of placing the new script in the original 1000 delimited folder structure, it will instead place the new script in the 'Stored Procedures' folder directly.
That is an interesting scenario. I will check it out one of these days.
Here is my 2 cents. After the initial load of all the database objects into a database project I(or dev team) stop the practice of adding new SPs or any objects directly to the database through SSMS. Instead, I add them to the Database Project and deploy to all the servers I need them to go to. The database project acts like the true source of code from that point on-wards. On top of that, you can leverage TFS branching feature to keep QA version, Prod version of the Database Projects. I also try to give meaningful names to the folders to categories the SPs under the Stored Proc folder which helps in my future code maintenance.
In a database project DB2 has references to DB1. When I make a dacpac of DB1 and add a reference to the dacpac in DB2, then the project compiles without error.
Since DB1 and DB2 are in the same solution anyhow, I am trying to add a database reference instead of the reference to the dacpac. Since DB1 and DB2 may reside on different servers with different names in production, I added $(parameters) for databases and servers. The project does not compile:
Error 1069 SQL71561: View: xyz has an unresolved reference to object
[$(server)].[$(dbname)].[someschema].[sometable].
The parameters are set correctly. Did I overlook something concerning database references?
First just to verify that the projects themselves are setup correctly.
You have a project in the solution for DB1.
You have a project in the solution for DB2.
To start with a clean slate (often easiest with database references - you cannot edit properties easily after the reference has been added). Remove any existing database references to DB1 from DB2 project.
Do a clean of the solution.
Build DB1 (Verify that a DACPAC has been created for DB1 in \bin\debug etc) and fix any errors if necessary.
In DB2 add a database reference to a solution item. Right click on References, select Add Database Reference. In the dropdown choose the first item (Database project in the current solution). Choose DB1.
At the bottom, select 'Different Database, Different Server' from the dropdown.
Enter the variables again. Verify that the example usage at the bottom indicates 'SELECT * FROM [$(server)].[$(dbname)].[Schema1].[Table1]' (Or similar depending on your choice of variable names). Take note of that sample and copy that to a note or clip somewhere.
That should resolve the issues. You have already changed the views \ procs to reference the variables.
I think the easiest rule here is if you aren't sure, delete the reference and add it again. There is no easy way to edit variable names etc. In addition, if DB1 build fails, then you will still get reference errors like above.
I hadn't noticed that the referenced database projects in my solution did not compile in Visual Studio because of compile errors. Once the referenced projects compiled, the reference to those projects also worked.
Being able to extract a dacpac in Visual Studio is no indication for the circumstance that the project compiles; when extracting a dacpac directly from a database the external references of that database will be valid while the database project must be provided with those references first.
I have created a new Sql 2008 Database Project in Visual Studio 2010. I imported the database objects and only kept the stored procedures. That all worked as expected. Where I have the problem is that it tries to deploy the entire set of procedures each time. I expect it to only create the deployment script for the delta. I am pretty sure that I combed every setting, but I can't find it. So if someone could first validate that this is possible and second tell me where to look. I need to do this because we only deploy the stored procedures with each release, the database schema is not modified.
Do a Schema compare of the project (as source) with the database where you want to deploy (as target). Once shcem comparison results are shown you have a choice to select which changes you want to deploy and then click the button "Export to T-SQL Editor". It will create the delta script.
I use SQL 2008 Database Project to keep track of all my database changes and easilly update databases by running schema compares on them.
A bad thing is that I need to have VS2010 on the machine I want to perform the schema compare.
Currently I've been able to open a door on the remote servers and connect to them, executing the schema comprare on my machine but it would be great if I could execute everything right on the destination server.
Is there a way to perform a schema compare using nothing but the generated DB Project schemas?
I'm not sure why is it a bad thing that you have SQL2008 databases and work with VS2010. I do it every day. But if you just want to compare two DB schemas (meaning .dbschema files).here is an article on how to do it: http://msdn.microsoft.com/en-us/library/aa833435.aspx#comparewithvsdbcmd