SQLSourceControl Database Revision not set with v5 migration

datacentricity

We are running SQL Compare v11.6.3.1926 and I have noticed that if the resulting deployment script includes one or more v5 migrations then the block of code that sets the extended property for "SQLSourceControl Database Revision" (and SQLSourceControl Scripts Location for that matter) is missing.

This block appears as expected if there are no migrations.

Whilst I can work around this manually by pasting in the missing code block manually this kind of negates the point of using a tool to automatically generate database deployments.

Please help

Regards

Greg

DavidRG

Hi Greg,

Migrations V1 used extended properties -- called "SQLSourceControl Database Revision" and "SQLSourceControl Scripts Location"

Whereas, Migrations V5 now uses a table instead -- called "DeploymentMetadata" in the schema "RedGateLocal".

We are in the process of transitioning all of our tools away from Migrations V1 and on to Migrations V5 (there is an upgrade process in SQL Source Control 5 where you can upgrade any migration scripts that are in the old format if you've got any).

What you're observing is an effect of us removing some of the Migrations V1 code but not all of it -- basically when SQL Compare goes down the new Migrations V5 code path it doesn't add the extended properties, but when it goes down the old Migrations V1 code path it does add them.

It should be fine that the extended properties are sometimes missing, by which I mean, it shouldn't cause any problems to automated database deployments. If you observe any weird behaviour with the extended properties being missing then get back in touch, and we'll investigate

If you're relying on the extended properties yourself in your own code, then you should now start relying on the DeploymentMetadata table -- it's documented at https://documentation.red-gate.com/disp ... ntMetadata

datacentricity

Thanks for the quick response and I understand the reason behind this behaviour.

However, having the TFS (or other repo) revision/changset number recorded in the database can be a really useful overall indicator of what version of the code has already been deployed to the target database. I know that it is not an absolute indicator but it can be very helpful.

Can I ask that this feature be retained (even if it is an optional setting in SQL Compare) as I'm sure we are not the only team to find this extended property useful.

Many thanks,