Deployment script ordering of objects

brendan_t

Hi

When generating a deployment script after doing a schema comparison, the ordering of the objects that are being created/modified isn't always consistent. That makes it difficult when using a text comparison tool to identify incremental differences between deployment scripts.

It would be nice if given the same set of differences, we could expect to get the exact result in a deployment script. This doesn't seem to be the case at the moment. Is there a setting I am missing, or any way to ensure objects appear in the same order in separate comparisons?

Thanks
Brendan

Chris Auckland

Thanks for your post.

Is the script that's being generated in a different order still functionally correct, or does are the scripts invalid every so often?

brendan_t

Hi Chris, thanks for your reply

The script is still functionally correct and can be executed successfully. Its more of a source control traceability issue. Unfortunately we do not have personal databases dedicated to a certain project or piece of work, so when we produce schema comparisons, we often only want to include a subset of the changes in the deployment script. Being able to then compare the deployment script with a previous deployment to ensure we have only captured the changes we want is important. It makes it difficult when objects appear in different parts of the script and are identified as differences by text comparison tools.

I assume there is a degree of ordering implemented to ensure dependencies are applied in the correct order etc. Apart from that, the ordering seems arbitrary as sometimes it is the same as previously, but not always. I thought it might be simple enough to add additional ordering criteria to ensure a specific order is retained each time.

cheers
Brendan

Eddie D

Hi Brendan

I have further explanation from a colleague in the Development Team.

The order that objects in the deployment script appear can be dependent on the order that the database gave them to us in the first place. So when Schema Compare for Oracle queries the system tables, the objects are listed in whatever order the database decides to pass us the information to Schema Compare. That order can change as the database manages its system tables.

When creating the Deployment Script, the dependency order is the most important criteria. The fact that Table_B gets created before Table_A but on the next occasion you create a deployment script, Table_A is created before Table_B is immaterial, it is the dependency order that is important and that the deployment script or when run is successful.

Many Thanks
Eddie

brendan_t

Hi Eddie

Yes I understand, and I suspected that is what was occurring. Perhaps you could consider adding extra ordering criteria to the system table queries for future releases? That would improve the usefulness of this tool a great deal in my case, and hopefully for others too.

Thanks for the response
Brendan

dennisjones

Has there been any movement or updates related to this issue?  We see the same thing, not with the order of tables, but with the order of check constraints (and interestingly, only with check constraints).  We are using the SQL Compare command line, version 13.6.1.7928.  Like Brendan, for us, it is a version control issue.  With no changes to a table, different developers on different machines get different results.

Dennis

David Atkinson

dennisjones said:

Has there been any movement or updates related to this issue?  We see the same thing, not with the order of tables, but with the order of check constraints (and interestingly, only with check constraints).  We are using the SQL Compare command line, version 13.6.1.7928.  Like Brendan, for us, it is a version control issue.  With no changes to a table, different developers on different machines get different results.

Dennis

@dennisjones - are you referring to SQL Compare (for SQL Server) or Schema Compare (for Oracle)?

dennisjones

@David Atkinson,  we use SQL Compare with SQL Server.

I am attaching an example of what can happen when different developers generate a delta for the same table.  Each developer has their own local database, but everything is automated via scripts, so our databases and delta scripts are all created the same way.  This is why it seems so strange that we would get different results.

Thank you,

Dennis