Activity overview
Latest activity by AdamB
The snapshot is the current schema of the project (i.e. the shadow, which is created from the project, which is why the shadow database is needed to make it), and not the target. This snapshot is then compared to the current schema of the target database to create the drift report. It is compared to the previously deployed snapshot to create the diff report. / comments
The snapshot is the current schema of the project (i.e. the shadow, which is created from the project, which is why the shadow database is needed to make it), and not the target. This snapshot is t...
Whilst this is deprecated, there are currently no plans to remove this functionality from SQL Change Automation. If you do wish to migrate to SQL Compare Filters, the filter file can be manually created with going through the SQL Compare UI, so no purchase is needed. An example filter file Filter.scpf can be found in the documentation. The example excludes a table called MyTable with the following block: <Table version="1">
<Include>False</Include>
<Expression>((@NAME = 'MyTable'))</Expression>
</Table>The Expression here can be changed to any valid syntax for a WHERE clause in SQL in order to configure what is included or excluded. / comments
Whilst this is deprecated, there are currently no plans to remove this functionality from SQL Change Automation.If you do wish to migrate to SQL Compare Filters, the filter file can be manually cre...
I'm sorry to say that at the present time we don't support importing and then resolving conflicts in the tool window. Another possible option to avoid this kind of conflict is to edit programmable objects offline directly in the project rather than on the development database. If you want to execute them whilst working in this way, you could have the programmable object file from the project open in SSMS and run it as you make changes. / comments
I'm sorry to say that at the present time we don't support importing and then resolving conflicts in the tool window. Another possible option to avoid this kind of conflict is to edit programmable ...
The simplest solution is for Developer B to make sure to import before pulling the changes from Developer A. However, if the pull happens first you're correct there may not be a way to import. In this case, Developer B could revert to before the pull, import, then pull again. Alternatively, they can manually edit the programmable object in the project so that it contains the desired changes from both developers, and then deploy the object to the database. / comments
The simplest solution is for Developer B to make sure to import before pulling the changes from Developer A. However, if the pull happens first you're correct there may not be a way to import. In t...