Comments
Sort by recent activity
2 options:
OPTION 1:
Write your own powershell rather than using the default step template.
For example:
$scriptsFolder = "C:\Work\scripts" #replace with the location of your nuget package, probably using one of the #[Octopus.action[stepname]... system variables
$test = New-DlmDatabaseConnection -ServerInstance "test01\sql2014" -Database "Test" -Username "sa" -Password "P@ssw0rd" # Username and password only necessary if using SQL Auth. ServerInstance and Database should probably be parameterised
$syncResult = Sync-DlmDatabaseSchema -Source $scriptsFolder -Target $test
Out-File $syncResult.UpdateSql -FilePath "C:\Work\update.sql"
(See example 4 in docs for details here: https://documentation.red-gate.com/dlma2/cmdlet-reference/sync-dlmdatabaseschema)
OPTION 2:
Use 2 steps:
1. Redgate - Create Database Release - https://library.octopusdeploy.com/step-templates/c20b70dc-69aa-42a1-85db-6d37341b63e3/actiontemplate-redgate-create-database-release
2. Redgate - Deploy from Database Release - https://library.octopusdeploy.com/step-templates/7d18aeb8-5e69-4c91-aca4-0d71022944e8/actiontemplate-redgate-deploy-from-database-release
The first step will create various resources, including a plain sql script and a nice html diff report in advance of deployment. Both will be uploaded as an artifact. You could optionally add a "Manual intervention" step in between the create and deploy steps to enable a review. Perhaps just scope that to the production/pre-production environment?
WHICH TO CHOOSE?
Option 1 is quicker/simpler but requires writing your own PS
Option 2 does not require custom scripting and enables review, but the script is created in advance and it's a slightly more complex process. Also, your deployments will take longer. / comments
2 options:
OPTION 1:
Write your own powershell rather than using the default step template.
For example:
$scriptsFolder = "C:\Work\scripts" #replace with the location of your nuget package, probabl...
If you don't include the temporary database switch it uses localDB on the agent as the defualt! ;-P
I guess the question is will your references resolve properly from local DB to the dependent databases. (e.g. if you used three part names - db.schema.table) then those dbs will also need to exist on localdb. / comments
If you don't include the temporary database switch it uses localDB on the agent as the defualt! ;-P
I guess the question is will your references resolve properly from local DB to the dependent data...
Point DLMA at a dev or test server that has all the dependent objects. It will build the database on that server, where all the dependencies will exists, and it will delete the database when done. / comments
Point DLMA at a dev or test server that has all the dependent objects. It will build the database on that server, where all the dependencies will exists, and it will delete the database when done.
You need to handle that separately. / comments
You need to handle that separately.
You say "on the second time of deployment".
Have you tried to redeploy the same release against the same DB twice?
You should note that a DlmDatabaseRelease includes a specific upgrade script (in your case, I imagine it inserts some data). If you run the release twice it will try to run that upgrade script twice. This should be caught in the pre-deployment drift check (unless you have disabled it) and the deployment should be aborted.
If you want DLM Automation to generate a script on the fly to just make it match your source you should use the sync cmdlet instead. The idea of a DlmDatabaseRelease is that you can re-use the same deployment script in multiple environments. For example, if you wanted to do a dry-run deployment on a staging or pre-prod DB / comments
You say "on the second time of deployment".
Have you tried to redeploy the same release against the same DB twice?
You should note that a DlmDatabaseRelease includes a specific upgrade script (in y...
Use SQL Compare.
SQL Data Compare deploys the data contained in tables. To deploy the table itself use SQL Compare. / comments
Use SQL Compare.
SQL Data Compare deploys the data contained in tables. To deploy the table itself use SQL Compare.
If the user has a SQL Toolbelt licence - yes. Otherwise no. / comments
If the user has a SQL Toolbelt licence - yes. Otherwise no.
To install tSQLt on a DB, follow these instructions:
If using Redgate SQL Test: https://documentation.red-gate.com/sqt2/adding-a-database-to-sql-test
If not using Redgate SQL Test: http://tsqlt.org/user-guide/quick-start/ / comments
To install tSQLt on a DB, follow these instructions:
If using Redgate SQL Test:https://documentation.red-gate.com/sqt2/adding-a-database-to-sql-test
If not using Redgate SQL Test:http://tsqlt.org/u...
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...