SQL Compare 7 /Include:Trigger option

pellben

We've used SQL Compare 6 when we deploy form VS Studio and everything running well, now we upgrade SQL Compare 7 and we got this Error Message

Invalid value for switch /include: Trigger. Please use SQLCompare.exe /?
or SQLCompare.exe /verbose /? for more information.

Does that means /Trigger option are now not suported ?

thanks

David Atkinson

If I recall correctly, this 'object' was removed because it wasn't actually working since DML Triggers are simply part of a table definition in SQL Compare, and will be included in the comparison by default unless the IgnoreTriggers option is set (see the /options section in the verbose command line help).

Kind regards,

David Atkinson
Red Gate Software

pellben

Thanks

but we are using migration scripts (SQLCMD) to deploy table changes and using SQLCompare to synchronize our Stored Procs, Functions, Views and Triggers, which come from source controlled files (database code objects). We do this using a build server.

So, what you are saying is that the new SQLCompare 7 is no longer supports Trigger ??? Trigger were successfully synchronized with version 6. Is there a workaround? Or can we get this feature back? For now, we will have to revert to version 6.

Regards,

David Atkinson

What I'm saying is that I don't think you need to revert to v6. As far as I'm aware, the /include:Trigger option was being ignored by SQL Compare in v6, and DML Triggers are always included if tables are included. So if you simply remove the Trigger parameter from your current command it should work as you expect.

Please try this and let me know if this doesn't work as expected.

Kind regards,

David Atkinson
Red Gate Software

pellben

We don't included tables in the comparison (since handled by our migration scripts) but the /include:trigger option set. Our triggers were always synchronized with v6. I don't think this option is ignored in v6.

Is there a way to do this with version v7?

You have to know that we are using a build server and SqlCompare.exe. We compare against source control files and a destination database, not against a source database. We are treating triggers as source code, just like stored proc, but not tables. Tables are NOT synchronized with SqlCompare.exe but by migration scripts.

David Atkinson

Can you confirm whether you are referring to DDL triggers or DML triggers here?

David Atkinson
Red Gate Software

pellben

We refering to DML Triggers

pellben

In the same way, when we use that command (we've removed /INCLUDE:Trigger option),
"SQLCompare.exe" /scripts1:"%DBScriptsPath%" /s2:"%SqlServer%" /db2:"%BName%" /include:View /include:Function /include:StoredProcedure /allowIdenticalDatabases /synchronize"

We have that error message


Registering databases
Unexpected error: Failed to locate the CLR assembly xxxx.yyy.CLR_Extensions for
the [dcs].[EvalCondition] stored procedure.
Failed to locate the CLR assembly xxxx.yyy.CLR_Extensions for the [yyy].[EvalCondition] stored procedure.
RedGate.SQLCompare.Engine.SqlCompareException
at RedGate.SQLCompare.CommandLine.CommandProcessor.d()
at RedGate.SQLCompare.CommandLine.CommandProcessor.e()
at RedGate.SQLCompare.CommandLine.CommandProcessor.Run()
at RedGate.SQLCompare.CommandLine.Startup.a(String[] )
Error occured while executing SQLCompare. SQLCompare aborted.

But the assembly exist on destination database. It was created before in Migration scripts. When we use SQL Compare 7 GUI , that will run, we can create SP's.

David Atkinson

Using SQL Compare v6.2 I've just added a DML trigger to a 'scripts' version of AdventureWorks. I compared this against the AdventureWorks database itself (which has no trigger). I did a compare with and without the /include:Trigger switch and it didn't make a difference. If /include:Table isn't present as a parameter, the DML trigger is also ignored.

Would it be possible fo ryou to try this yourself? I can't see how this could have worked.

David Atkinson
Red Gate Software

Michelle T

The CLR error sounds like the scripts in DBScriptsPath contain a CLR stored procedure which depends on an assembly that doesn't exist in the script folder.

Can you confirm that the exact same synchronization (i.e. that script folder to that live database) works in the GUI?