Comments
Sort by recent activity
Hi,
I talked to my manager, and we're not comfortable sending a database snapshot, sorry. Is there anything else we can try from here? / comments
Hi,
I talked to my manager, and we're not comfortable sending a database snapshot, sorry. Is there anything else we can try from here?
I just verified, yes, we are already excluding users in all our filters. It seems that all the scripts get parsed even if they're excluded by a filter?
(These errors are coming from SQL Compare/SQL Data Compare, not SQL Source Control, by the way. I double-checked to make sure they're both at the latest version, just to be sure.) / comments
I just verified, yes, we are already excluding users in all our filters. It seems that all the scripts get parsed even if they're excluded by a filter?
(These errors are coming from SQL Compare/SQ...
Hi, I apologize for the late reply. We are now seeing this error on different servers and with different deployment scripts; it seems to be occurring with increasing frequency. It is still not reliably reproducible though.
Unfortunately, I've been moved to a new project so I don't have time to write an app using the SDK. If there is a simpler option or workaround then I could probably get some time to look into it.
One thought I had: we don't need to sync our users, they don't change frequently. Would it be possible to remove them from source control entirely? I'm concerned that it might cause dependency issues, but if there's a safe way to remove those scripts then I'm willing to try it. / comments
Hi, I apologize for the late reply. We are now seeing this error on different servers and with different deployment scripts; it seems to be occurring with increasing frequency. It is still not re...
Hi, thanks for the suggestions. My first thought was that the file is changing too. This is our automated build server, so nobody uses the machine but me. However I thought maybe part of the build process was changing the scripts, so I monitored the file during the build to see if it changed. It did not; in fact, the file's modified date is from months ago.
I had our IT team add the scripts folder to the antivirus exception list, but unfortunately, that didn't solve the problem either.
My earlier statement about this failing every other time is also no longer true; we had three consecutive successful runs last week, and two consecutive failures yesterday.
Please let me know if you have any other suggestions, or if there is more information I can gather to help. Thanks. / comments
Hi, thanks for the suggestions. My first thought was that the file is changing too. This is our automated build server, so nobody uses the machine but me. However I thought maybe part of the bui...
Yes, specifying /options:Default,NoTransactions works perfectly!
I guess I need to pay closer attention to the online docs, I'm sure I read that page at one point but apparently forgot all about it. Thanks for the help! / comments
Yes, specifying /options:Default,NoTransactions works perfectly!
I guess I need to pay closer attention to the online docs, I'm sure I read that page at one point but apparently forgot all about it...
The patch worked for me as well, thank you! / comments
The patch worked for me as well, thank you!
Oh, one thing to note about this version. It seems to be leaving a folder behind inside the Data folder. If I run it twice, the second run fails with a bunch of errors like the following:
Error: Ignored statement found in file
d:\build\Database\trunk\Data\634429737738099016\dbo.tablename_Data.sql
at line 1
If I delete that weird folder (634429737738099016) then it works fine. / comments
Oh, one thing to note about this version. It seems to be leaving a folder behind inside the Data folder. If I run it twice, the second run fails with a bunch of errors like the following:
Error:...
I'm getting this same error, but I can't use version 8 because that gives me an error about "Only x86 assemblies are currently supported." I have some tables that only exist on the second server, and I tried excluding them but I still get the error. Is there a workaround for this issue or do I have to wait until the next version is released? / comments
I'm getting this same error, but I can't use version 8 because that gives me an error about "Only x86 assemblies are currently supported." I have some tables that only exist on the second server, ...
Great, thanks! / comments
Great, thanks!
I think I figured it out... it seems that there was still a reference to the unlinked table in the RedGateDatabaseInfo.xml file. Once I removed that (and the /exclude:additional option) it worked as expected.
So is this a problem with the way that SQL Source Control unlinks tables? Is there a way that I can file a bug report about that? / comments
I think I figured it out... it seems that there was still a reference to the unlinked table in the RedGateDatabaseInfo.xml file. Once I removed that (and the /exclude:additional option) it worked ...