1

We have an automated build process via TFS, TFS database projects, and vsdbcmd. When deploying the database project to our database server, the generated SQL script attempts to 'ALTER' certain stored procedures, even though those stored procedures do not net yet exist in the target database. Instead, the SQL script schould contain 'CREATE' statements for those stored procedures. This obviously causes the database deployment to fail, as there is no way to 'ALTER' a stored procedure that does not exist.

Does anyone have any ideas about what may be causing this, or how it can be fixed?

Kamau Malone
  • 570
  • 1
  • 5
  • 16

3 Answers3

2

are you using VSDBCMD to deploy to the target database? VSDBCMD should take as input a .dbschema file and a connectionstring, and it generates an appropriate SQL file. If you generated the SQL file while pointing to a different DB, then it won't work on a DB server that is in a different state.

Dylan Smith
  • 22,069
  • 2
  • 47
  • 62
  • This seems to be just the problem - the connection string is pointing to the correct target connection string, yet it still generates an incorrect SQL file. – Kamau Malone Jul 16 '12 at 15:40
1

We are using a similar process in our TFS Build, I am pretty sure this handles successfully newly inserted elements (tables, columns, SPs, indices etc).

At first we generate the .dbschema of the old DB by invoking VSDBCMD with a:

/a:import /dsp:sql /model:C:\PATH\old.dbschema /cs:"Server=SQLSERVER;Integrated Security=False;Pooling=False;Initial Catalog=OLDDB;User=username;Password=password;

Then we we generate the .dbschema of the newest state of the DB, which at an earlier step has been deployed (via MSBuild):

/a:import /dsp:sql /model:C:\PATH\new.dbschema /cs:"Server=SQLSERVER;Integrated Security=False;Pooling=False;Initial Catalog=NEWDB;User=username;Password=password;

We finally invoke VSDBCMD for a third time, so that it generates the ALTER:

/a:deploy /dsp:sql /model:C:\PATH\new.dbschema /targetmodelfile:C:\PATH\old.dbschema /DeploymentScriptFile:C:\PATH\DB_Alter.sql /p:Targetdatabase="DB"

This generated DB_Alter.sql can be applied on the production-SQL running the previous state of the DB, in order to shape it into the latest.

What you are implying could either be traced back to you not forming the VSDBCMD arguments correctly, or a direct bug of the tool. In your place, I would manually experiment with the tool in order to ensure which of the two applies.
To my best knowledge, the above presented procedure works OK, so I tend to believe there is something wrong with your implementation.

pantelif
  • 8,524
  • 2
  • 33
  • 48
0

Found out what was wrong: In TFS, the table definition did not have a schema prefix. So instead of (for example)

CREATE TABLE [dbo][TableName]

it was 

CREATE TABLE [TableName]

The lack of a schema specified meant that when QA ran vsdbcmd, the schema assigned to the table was the default schema of the individual running vsdbcmd. So what was actually created was effectively as if we had specified:

CREATE TABLE [QAUser_SCHEMA].[TableName]

This caused vsdbcmd, when later run by another individual whose default schema was [dbo] to receive the error that we saw, basically generating an ALTER statement because the stored procedure had already been created, although under a different schema.

One would think that even with the incorrect schema specified initially, that once the [dbo] schema was specified for the procedure that it would be considered a "different" procedure, however that was not the case. Dropping the original, version of the procedure (the one with the [QAUser_SCHEMA]), and then re-running vsdbcmd solved the problem.

TLDR; Always prefix database objects in your database projects with a schema name.

Kamau Malone
  • 570
  • 1
  • 5
  • 16