Correct ordering of DB objects in synchronization script

dariasbrownCJ

Does SQL Compare 9 or 10 Standard support the following:

Dependency checking so objects are scripted in the correct order for updates. Database objects are scripted in the correct order even if SQL metadata (sysdepends) is broken.

Thanks,

Darias

Brian Donahue

Hi Darias,

SQL Compare has had its' own text-parsing dependency engine since about version 3, so you should be pretty safe with dependencies, even if sysdepends has a problem. It needs this parsing support in order to work with scripts as a data source, so it's reliable.

When comparing a live database, v10 uses sysdepends as a starting point and then adjusts depending on the definition of the objects in the database.

dariasbrownCJ

Brian,

Thanks for your response. I have an issue with the SQL Compare parser because it has been creating objects that depend on tables ahead of the table DDL.

Darias

Brian Donahue

If there is a problem with this then there is probably some defect in that version. Is it possible to upgrade to v10? We don't provide support for prior versions but we can fix it if there is a problem with the current version.

SPeacock1978

I am having a similar problem. I have a table that has a full text index on it and there is a stored procedure that uses this functionality. When I use SQL Compare 10 to create a deployment script the scripts creates the objects in the following order:

1) Create table
2) Create indexes
3) Create stored proc
4) Create full text index on table

As the full text index does not exist at the time the stored proc is being created I get the following error...

Cannot use a CONTAINS or FREETEXT predicate on table or indexed view 'tblCompany' because it is not full-text indexed.

Is there a way to control the ordering of the objects in the scripts or is it all automatic?

Michelle T

That one's a particularly persistent bug caused by a compromise solution to the problem that full text operations interact poorly with transactions - it's on the list of issues we're actively looking at, but currently the workaround is to do two deployments - first with the fulltext objects and second with the procedures that depend on them.

We hope to have this fixed for v11.