I wanted to pass along this link to an MSBuild task for dbDeploy.NET: hhttp://www.distributethis.com/?p=41. It would be helpful if you guys would consider including something similar in future releases.
Thanks for any consideration.
Regards,
Michael
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I actually have an MSBuild task for dbdeploy.net for at least a year now :) It just happens that I developed it in VS2008 and have not taken the time to build it in VS2005 and commit to the source tree. Thanks for reminding me!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It seems there is a difference in how the released version of the dbDeploy scripts are generated and the newly compiled version (yet to be released) using the MSBuild task. There is a BEGIN TRANSACTION / COMMIT surrounding each script, which is causing issues. Consider the case where the script begins with CREATE PROCEDURE, which results in the following output:
BEGIN TRANSACTION
CREATE PROCEDURE ...
...
GO
This script will generate an exception stating that a CREATE PROCEDURE statement must begin with "CREATE PROCEDURE" (and not "BEGIN TRANSACTION"). As an interim solution, I've modified the ApplyChangeDoScript() and ApplyChangeUndoScript() methods within Net.Sf.Dbdeploy.ChangeScriptExecuter to call _dbmsSyntax.GenerateStatementDelimiter() after the calls to GenerateBeginTransaction() and GenerateCommitTransaction().
As always, any help is appreciated. Incidentally, we use Microsoft SQL Server 2005 (and soon to be 2008).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
After additional testing, I had to back out my modification and also comment out the GenerateBeginTransaction and GenerateCommitTransaction calls that were added in SVN revisions 23 and 24 for ChangeScriptExecuter. Simply adding the GenerateStatementDelimiter call still causes syntax issues in some scripts.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks for pointing this out. I've forgotten this issue. I remembered running into this in my last project and fixed it but I don't remember the details :) I wonder perhaps instead of always applying the begin/go statements, an option should be available so users can control whether the statements are printout?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
An option to control whether the BEGIN TRANSACTION / COMMIT TRANSACTION is printed would be helpful. We require that all dbDeploy scripts must control a transaction within their scope of execution, provide an UNDO section, and allow for repeatable execution (may be run many times). Therefore, we'd simply direct dbDeploy to not include the transaction logic.
As always, I appreciate your help.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I wanted to pass along this link to an MSBuild task for dbDeploy.NET: hhttp://www.distributethis.com/?p=41. It would be helpful if you guys would consider including something similar in future releases.
Thanks for any consideration.
Regards,
Michael
I actually have an MSBuild task for dbdeploy.net for at least a year now :) It just happens that I developed it in VS2008 and have not taken the time to build it in VS2005 and commit to the source tree. Thanks for reminding me!
Awesome! Look forward to seeing it soon :-)
Added MSBuild task project to the solution. Try it out and let me know if you have any other request :)
Thanks Alex. I tried it out and all works very well. I look forward to your next formal release.
Regards,
Michael
It seems there is a difference in how the released version of the dbDeploy scripts are generated and the newly compiled version (yet to be released) using the MSBuild task. There is a BEGIN TRANSACTION / COMMIT surrounding each script, which is causing issues. Consider the case where the script begins with CREATE PROCEDURE, which results in the following output:
BEGIN TRANSACTION
CREATE PROCEDURE ...
...
GO
This script will generate an exception stating that a CREATE PROCEDURE statement must begin with "CREATE PROCEDURE" (and not "BEGIN TRANSACTION"). As an interim solution, I've modified the ApplyChangeDoScript() and ApplyChangeUndoScript() methods within Net.Sf.Dbdeploy.ChangeScriptExecuter to call _dbmsSyntax.GenerateStatementDelimiter() after the calls to GenerateBeginTransaction() and GenerateCommitTransaction().
As always, any help is appreciated. Incidentally, we use Microsoft SQL Server 2005 (and soon to be 2008).
After additional testing, I had to back out my modification and also comment out the GenerateBeginTransaction and GenerateCommitTransaction calls that were added in SVN revisions 23 and 24 for ChangeScriptExecuter. Simply adding the GenerateStatementDelimiter call still causes syntax issues in some scripts.
Thanks for pointing this out. I've forgotten this issue. I remembered running into this in my last project and fixed it but I don't remember the details :) I wonder perhaps instead of always applying the begin/go statements, an option should be available so users can control whether the statements are printout?
An option to control whether the BEGIN TRANSACTION / COMMIT TRANSACTION is printed would be helpful. We require that all dbDeploy scripts must control a transaction within their scope of execution, provide an UNDO section, and allow for repeatable execution (may be run many times). Therefore, we'd simply direct dbDeploy to not include the transaction logic.
As always, I appreciate your help.
A new option, "UseTransaction" for MSBuild and "useTransaction" for NAnt, has been added to svn. This applies to both Do and Undo scripts, of course.
Let me know if you have other features you think will be useful.