Comments
Sort by recent activity
Ok, thanks. This issue is really impacting us and forcing us to go through some painful workarounds... is there a date when this fix will be available for the SDK? / comments
Ok, thanks. This issue is really impacting us and forcing us to go through some painful workarounds... is there a date when this fix will be available for the SDK?
Hi, still waiting for an updated version of the SDK that would address this problem that has already been fixed in SQL Compare 10. Is there a patch available at this time? Thanks. / comments
Hi, still waiting for an updated version of the SDK that would address this problem that has already been fixed in SQL Compare 10. Is there a patch available at this time? Thanks.
Hi Brian,
Sorry... I've just noticed your reply. We are running into the same issue again... if you have a patch, it would be very helpful. But this is happening with the SQL Compare SDK.. not the command-line.
Would your patch work?
Thanks / comments
Hi Brian,
Sorry... I've just noticed your reply. We are running into the same issue again... if you have a patch, it would be very helpful. But this is happening with the SQL Compare SDK.. not the ...
Of course, a few minutes after submitting this realized that after the first rename statement we'll have a Charge table again. But, the second rename throws an error and I'm not sure why.
I also see this behavior when I run the comparison / deploy using the SQL Compare SDK.
Thanks / comments
Of course, a few minutes after submitting this realized that after the first rename statement we'll have a Charge table again. But, the second rename throws an error and I'm not sure why.
I also se...
I think it does. Thank you. / comments
I think it does. Thank you.
That syntax does not appear to be valid:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'CHECK'. / comments
That syntax does not appear to be valid:
Msg 156, Level 15, State 1, Line 1
Incorrect syntax near the keyword 'CHECK'.
Excellent! This solves the problem.
Thank you. / comments
Excellent! This solves the problem.
Thank you.
Hi Brian, thank you for your reply.
In my example, I was referring exclusively to the second scenario. So, assuming that my table already has all its constraints and they were enabled when they were initially created. I am taking a snapshot of the database and then running this command:
ALTER TABLE [dbo].[SystemSW] NOCHECK CONSTRAINT [FK_SystemSW_Software]
If I run SQL Compare at this point, there is a difference between the snapshot and the live database, which is expected.
Next, I run this command:
ALTER TABLE [dbo].[SystemSW] CHECK CONSTRAINT [FK_SystemSW_Software]
I would expect SQL Compare to show no differences... but it actually still shows that the NOCHECK flag is enabled. / comments
Hi Brian, thank you for your reply.
In my example, I was referring exclusively to the second scenario. So, assuming that my table already has all its constraints and they were enabled when they wer...