Activity overview
Latest activity by Mark J
Sorry about this! We're investigating it now. It looks like an update to one of our shared libraries might have had some unexpected effects. We'll let you know when we have a fix available. / comments
Sorry about this! We're investigating it now. It looks like an update to one of our shared libraries might have had some unexpected effects. We'll let you know when we have a fix available.
Honestly I'm not exactly sure what's causing your problem at the moment (it's been some time since we implemented temporal table support so the code isn't particularly fresh in my head) but I think the cause is to do with the way that SQL Compare currently just reads the name of the history table and deploys that, rather than treating the history table as an independent object with its own properties.
I think you're probably right in that this case it's more likely to be a problem with mappings than a problem with customisation as such, but if we have the history table as its own thing in the code then we're more likely to be able to apply mapping to it properly.
Either way, I'll try and make sure we do something to improve this situation [image] / comments
Honestly I'm not exactly sure what's causing your problem at the moment (it's been some time since we implemented temporal table support so the code isn't particularly fresh in my head) but I think...
Thanks for the feedback - this is actually something we're hoping to look at soon. Our current implementation of temporal table support in SQL Compare doesn't preserve any customisation on the history table, such as putting it into a different schema (like the case here) or adding extra indexes and constraints (which some of our other customers have run into). We'll be looking to see if we can improve the situation so that we do a better job here, although we want to try and avoid complicated dependency issues that could arise if we start treating the history table as another first-class table. / comments
Thanks for the feedback - this is actually something we're hoping to look at soon. Our current implementation of temporal table support in SQL Compare doesn't preserve any customisation on the hist...
This isn't currently a feature in SQL Data Compare as far as I know, but you could write a script based on sp_MSForEachTable such as the one described here: https://stackoverflow.com/a/156813/895407 before doing the SQL Data Compare comparison. Would that work for you? / comments
This isn't currently a feature in SQL Data Compare as far as I know, but you could write a script based on sp_MSForEachTable such as the one described here: https://stackoverflow.com/a/156813/89540...
Hi - I'll take a look at the discussion in https://forum.red-gate.com/discussion/81291/truncate-target-database-first-then-insert-the-source-data since this appears to be a duplicate / comments
Hi - I'll take a look at the discussion in https://forum.red-gate.com/discussion/81291/truncate-target-database-first-then-insert-the-source-data since this appears to be a duplicate
We don't have this in Compare itself at the moment, but if you want to work with migration scripts you can do so through SQL Source Control - eg there's a worked example here: https://documentation.red-gate.com/display/SOC5/Splitting+a+column+without+data+loss / comments
We don't have this in Compare itself at the moment, but if you want to work with migration scripts you can do so through SQL Source Control - eg there's a worked example here: https://documentation...
It sounds like you're using DLMA and the deployment process is quitting early because of the data loss warnings that are being output. I think you should be able to prevent that from happening by specifying the -AbortOnWarningLevel or -Force options documented in https://documentation.red-gate.com/display/DLMA2/Sync-DlmDatabaseSchema / comments
It sounds like you're using DLMA and the deployment process is quitting early because of the data loss warnings that are being output. I think you should be able to prevent that from happening by s...
I don't think this is directly possible at the moment, unfortunately. However, in SQL Compare 12 we've added 'Last modified' dates to the object list in the comparison results, so it's a lot easier than before to see which objects have been modified more recently : https://documentation.red-gate.com/display/SC12/SQL+Compare+12.1+release+notes - I hope that's helpful, even though you'd still need to manually select the objects you want to deploy. / comments
I don't think this is directly possible at the moment, unfortunately. However, in SQL Compare 12 we've added 'Last modified' dates to the object list in the comparison results, so it's a lot easier...
Thanks for the suggestion! We do currently have a uservoice entry open for a similar feature: https://redgate.uservoice.com/forums/141379/suggestions/4260526 and we'd love for you to get in contact via research@red-gate.com to tell us a bit more about your process. / comments
Thanks for the suggestion! We do currently have a uservoice entry open for a similar feature: https://redgate.uservoice.com/forums/141379/suggestions/4260526 and we'd love for you to get in contact...
Hi there
I think this behaviour is improved in our latest Frequent Updates release (11.1.7.47) - Compare should now refresh views less often; it will no longer refresh views unrelated to the deployment and will refresh no views if the 'Include Dependencies' option is disabled / comments
Hi there
I think this behaviour is improved in our latest Frequent Updates release (11.1.7.47) - Compare should now refresh views less often; it will no longer refresh views unrelated to the deploy...