Comments
Sort by recent activity
Hi there,
First, a quick question:
Have you added tSQLt on your dev DB and committed it to source control?
If not, the reason you get the error is that when DLMA builds the DB it doesn't have the tSQLt objects (because your source code doesn't have the tSQLt objects) - hence the error.
If you do have the tSQLt objects in source control, are you using a persistent temporary database (i.e. a specific named database using the -TemporaryDatabase parameter) or did you exclude that parameter, allowing DLMA to create a temporary scratch DB for you with a GUID for a name?
If you are using the -TemporaryDatabase parameter, have you set TRUSTWORTHY to ON on that database? TRUSTWORTHY is required to be on in order for tSQLt to work. I believe the cmdlet will deploy tSQLt for you (assuming it's in source control), but tSQLt will only work if the DB has TRUSTWORTHY enabled. If it is not enabled you can get some unintuitive error messages.
To enable trustworthy:
ALTER DATABASE dbname SET TRUSTWORTHY ON;
Note: Do not do this on production. TRUSTWORTHY is a bad idea on production: https://stackoverflow.com/questions/27006432/security-risks-of-setting-trustworthy-on-in-sql-server-2012
Let me know if that helps. / comments
Hi there,
First, a quick question:
Have you added tSQLt on your dev DB and committed it to source control?
If not, the reason you get the error is that when DLMA builds the DB it doesn't have the t...
How's your PowerShell? https://documentation.red-gate.com/clone2/automation/powershell-worked-examples / comments
How's your PowerShell?https://documentation.red-gate.com/clone2/automation/powershell-worked-examples
Fantastic. Just shout if you need any more help. / comments
Fantastic. Just shout if you need any more help.
Follow these instructions: https://documentation.red-gate.com/ddb1/investigating-schema-changes/using-filters / comments
Follow these instructions:https://documentation.red-gate.com/ddb1/investigating-schema-changes/using-filters
I would use branches instead.
I wrote a blog post a little while ago about a format for discussing branching/shelving strategies whilst attempting to avoid flame wars. You may or may not find it useful: http://workingwithdevs.com/branching-reality/ / comments
I would use branches instead.
I wrote a blog post a little while ago about a format for discussing branching/shelving strategies whilst attempting to avoid flame wars. You may or may not find it us...
You can script this stuff out in SQL Compare or SQL Data Compare, but I would use Redgate SQL Source Control. This allows you to link your dev DB in SSMS to your VCS or just a plain old directory on your filesystem ("working folder") and to keep it up to date.
However, it won't give you the PRINT statements.
For deployment, if you already own SQL Toolbelt, why don't you use DLM Automation to handle deployments in the recommended and supported fashion? Unless I'm mistaken the upgrade scrpits it generates will have your PRINT statements. / comments
You can script this stuff out in SQL Compare or SQL Data Compare, but I would use Redgate SQL Source Control. This allows you to link your dev DB in SSMS to your VCS or just a plain old directory o...
Sorry, I've not come across the log in issue before. I can't imagine it's intended that you cannot activate on machines without internet. Hopefully someone from Redgate can advise. / comments
Sorry, I've not come across the log in issue before. I can't imagine it's intended that you cannot activate on machines without internet. Hopefully someone from Redgate can advise.
https://www.red-gate.com/webactivation/activate / comments
https://www.red-gate.com/webactivation/activate
Also, Schema Compare is your friend. And the more progress you can make on the human stuff above, the easier that merge will be. / comments
Also, Schema Compare is your friend. And the more progress you can make on the human stuff above, the easier that merge will be.
This is all a question about source control branching. You should manage all the source code for all the different branches in source control.
There are of course plenty of different branching strategies with different pros and cons and plenty of people who feel strongly about one way or the other being the best and I don't fancy getting drawn into one of those debates. Ideally, however, your branching strategy should match your reality.
I wrote a bit more detail on that point here: http://workingwithdevs.com/branching-reality/
Of course, that approach will have limitations based on the tooling you choose. Git, for example, is far better able to cope with complicated branching strategies than TFSVC or SVN, but its also a bit of a learning curve and complicated branching strategies can get pretty confusing pretty quickly. It's not a perfect science despite what you may read.
However, once you have fixed the source control branching issue you should be able to deploy your code based on the source code, rather than trying to sift through a bunch of work in progress and copy specific changes from one database to another.
I wrote about one POC creating an Oracle database deployment pipeline based on source control here: http://workingwithdevs.com/continuous-delivery-oracle-databases-bamboo-redgate-1/ / comments
This is all a question about source control branching. You should manage all the source code for all the different branches in source control.
There are of course plenty of different branching stra...