Comments
Sort by recent activity
I haven't watched these videos myself, but they sound like they cover your scenario: Getting Consistent Builds: Fixing Cross-Database Dependencies: [image] https://www.youtube.com/watch?v=xm6Arpbz078 and Managing Cross Database Dependencies in Builds - Two Popular Options: [image] https://www.youtube.com/watch?v=20xJTUokUxM.
/ comments
I haven't watched these videos myself, but they sound like they cover your scenario: Getting Consistent Builds: Fixing Cross-Database Dependencies: https://www.youtube.com/watch?v=xm6Arpbz078 andMa...
You have a SQL Server instance that hosts your "build database": the database that SQL Change Automation creates from source control each time you want to build your database. For example, the build database that you point SQL Change Automation at could be called: "OrderTracker_Build", this entire database gets cleaned and re-created from source control by SQL Change Automation on every build. As long as the stub database is in the same SQL Server instance, then objects that use cross database queries will compile. / comments
You have a SQL Server instance that hosts your "build database": the database that SQL Change Automation creates from source control each time you want to build your database. For example, the buil...
The creation of the stub is a manual one off task. There is no need to re-create the stub for each build as it won't change. / comments
The creation of the stub is a manual one off task. There is no need to re-create the stub for each build as it won't change.
A "fake stub" is just a version of the real database but without any data. When using SQL Change Automation, you store a representation of your database in source control as a set of .sql files that contain DDL statements e.g. CREATE TABLE ... etc. When you want make make a change, you update source control and use SQL Change Automation to create a database artifact which can then be used to update your target environments e.g. UA, Staging, Production etc. You need a temporary server for SQL Change Automation to create this database artifact. If you have views or stored procedures that reference another database on the same server, then you can create a "fake stub" database on the temporary server. e.g. Database in source control: OrderTracker Database *not* in source control: StaffTracker (fake) In OrderTracker: CREATE VIEW dbo.AllOrders AS SELECT OrderNumber, ... FROM dbo.Order INNER JOIN StaffTracker.dbo.Staff / comments
A "fake stub" is just a version of the real database but without any data.When using SQL Change Automation, you store a representation of your database in source control as a set of .sql files that...
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts are for occasional use only and can lead to performance issues...". I've not used them myself, but I guess schema changes with data migrations shouldn't happen that often, so you may be alright?
https://documentation.red-gate.com/display/SOC7/Working+with+migration+scripts
/ comments
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts ar...
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts are for occasional use only and can lead to performance issues...". I've not used them myself, but I guess schema changes with data migrations shouldn't happen that often, so you may be alright?
https://documentation.red-gate.com/display/SOC7/Working+with+migration+scripts
/ comments
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts ar...
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts are for occasional use only and can lead to performance issues...". I've not used them myself, but I guess schema changes with data migrations don't happen that often?
https://documentation.red-gate.com/display/SOC7/Working+with+migration+scripts
/ comments
There is a "Migrations" tab in the SSMS Redgate SQL Source Control plugin that allows you to combine schema changes with data migrations, however it has the following warning: "Migration scripts ar...
You could create a database on your local PC and point Redgate SQL Source Control to it, and also change your development model to dedicated, then you won't be affected by the nightly restore. Although, this does mean that you won't automatically have a fresh copy of Production data on your local PC every day, although this may not be desirable anyway if your production database contains customer data, think data protection/GDPR etc. / comments
You could create a database on your local PC and point Redgate SQL Source Control to it, and also change your development model to dedicated, then you won't be affected by the nightly restore.Altho...
No, they should not be in source control, I've excluded them from source control and it still works fine. / comments
No, they should not be in source control, I've excluded them from source control and it still works fine.
What about making your migration scripts environment aware e.g. IF (@@SERVERNAME = 'MyProductionServer')Assuming your database doesn't move servers in the meantime. I wouldn't use this technique for business logic in application code i.e. in a stored procedure, but for a one-off script I think it's Ok? / comments
What about making your migration scripts environment aware e.g. IF (@@SERVERNAME = 'MyProductionServer')Assuming your database doesn't move servers in the meantime. I wouldn't use this technique fo...