Activity overview
Latest activity by SamTouray
We had the same issue:
Export-DatabaseBuildArtifact, SQL Change Automation 4.2.20119.19650, Copyright © Red Gate Software Ltd 2014-2019
.\db\state\.git\objects\pack\pack-b5ae9c2c642d9f0554a0c735413733be13335d83.pack
##[error]Cannot generate NuGetPackage. File path: C:\Users\User1\AppData\Local\Temp\DLM Automation\ocohjn0z.s5o. Package: MyDatabase. Version: 1.0, Underlying error: Can not access a closed Stream..
In our case we are using Git for source control and our database scripts folder is in the VCS root, so it was attempting to include the .git folder in the generated NuGet package. Our .git folder was 60.8 MB!
I solved it by adding a task to delete the .git folder. I found out that it includes the .git folder by trying it on another source controlled database with a smaller .git folder and the generated NuGet package includes everything in the source folder, not just *.sql files. You can see this yourself by changing the extension of the NuGet package to .zip and opening in Windows Explorer. I am planning to move our database scripts folder to a sub-folder of the VCS root and then we won't need a task to delete the .git folder. Also, it's just a cleaner solution as we are then free to store other files/folders in our VCS root and they won't affect database package creation.
/ comments
We had the same issue:
Export-DatabaseBuildArtifact, SQL Change Automation 4.2.20119.19650, Copyright © Red Gate Software Ltd 2014-2019
.\db\state\.git\objects\pack\pack-b5ae9c2c642d9f0554a0c735...
Sorry, just saw your post about the build being on a hosted VM. If you're not able to run the build on an on-premise build agent then your'e correct in that you will have to find some way to script it (I've never scripted the creation of a non-source controlled database before). Are your test and production databases in Azure, because at some point you'll want to deploy your database changes and if your test/production databases are on premise then you probably need an on premise build agent anyway? / comments
Sorry, just saw your post about the build being on a hosted VM. If you're not able to run the build on an on-premise build agent then your'e correct in that you will have to find some way to script...
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...