Comments
Sort by recent activity
I'm not sure if this is the same problem you had.
I had setup SQL Compare, and SQL Data Compare, scripts as part of our automated build process and was getting error code 77 when running on our build agents.
Further investigation showed that the comparison was working but sqlcompare.exe was still returning this error causing the build to fail.
I tracked it down to the following lines in the log output:
Could not create licence distribution files. Please run as adminstrator if you wish to create these files.
Error occurred whilst writing new distribution licence to disk: Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
This was logged when the utility was first run, before starting comparison, but it caused error code 77 to be returned even when the comparison completed successfully.
It seems it needed to create a license file in the Red Gate program files folder (which the build agent user account didn't have rights to do).
I fixed it by running sqlcompare.exe once as an Administrator so that the license file was created. The build scripts could then be run as a non-privileged user without error. / comments
I'm not sure if this is the same problem you had.
I had setup SQL Compare, and SQL Data Compare, scripts as part of our automated build process and was getting error code 77 when running on our bui...
Thanks David. I hope you can implement it soon, as we won't be able to update our SQL Source Control installations until it is available. / comments
Thanks David. I hope you can implement it soon, as we won't be able to update our SQL Source Control installations until it is available.
Thanks for the reply David. I can't use the current EAP builds, they don't play nicely with our SQL Data Compare scripts for managing static data.
We're patiently waiting for this feature request so we can use SQL Source Control for managing data as well.
Do you know if this will make it into the next official release? / comments
Thanks for the reply David. I can't use the current EAP builds, they don't play nicely with our SQL Data Compare scripts for managing static data.
We're patiently waiting for this feature request s...
Hi David,
The problem we have is that the current EAP builds of SQL Source Control aren't usable because of the limited data support.
We use the tools in the following way:
1. A single SVN repository
2. SQL Source Control for developers to check-in changes to this source tree.
3. Custom SQL Compare and SQL Data Compare scripts to deploy changes from the repository to our test, staging, production environments
Testing we've done with the pre-release SQL Source Control have failed because it always tries to overwrite the data in the repository.
We won't be able to use the new release unless either we can completely disable data support in SQL Source Control, or the data support is enhanced to allow us to specify which columns to source-control.
Is it possible to disable source controlling of data in the release candidate, even when data exists in the SVN repository?
Jason / comments
Hi David,
The problem we have is that the current EAP builds of SQL Source Control aren't usable because of the limited data support.
We use the tools in the following way:
1. A single SVN reposito...
I'm having the same problem, introduced in the same way.
Database was working fine. Restored from a backup and now it fails with the "Failed to locate the CLR assembly..." exception even though the CLR assembly is properly installed, enabled and usable within a query. / comments
I'm having the same problem, introduced in the same way.
Database was working fine. Restored from a backup and now it fails with the "Failed to locate the CLR assembly..." exception even though the...
I have been having similar problems but I think (hope!) I've fixed it. We use the base monitor account as the credentials for monitoring remote servers.
I ran through the tests at http://www.red-gate.com/supportcenter/Content?p=SQL%20Monitor&c=SQL_Monitor/help/2.1/SM_Testing_data_collection.htm&toc=SQL_Monitor/help/2.1/toc1340335.htm and they failed at the perfmon step.
I was logging in using user@domain format. When I changed it to DOMAIN\user format it worked...
Don't know why. Anyway, I updated the credentials used for running the SQL Monitor 2 service and restarted it, all my monitors came online.
Hope this helps. / comments
I have been having similar problems but I think (hope!) I've fixed it. We use the base monitor account as the credentials for monitoring remote servers.
I ran through the tests at http://www.red-ga...