Comments
Sort by recent activity
I have emailed the error report before, but just did it now. I also note that the "complete error message" that can be shown on the bottom pane seems to have much more detail to it. I have emailed you a screenshot with that information in case it is helpful. / comments
I have emailed the error report before, but just did it now. I also note that the "complete error message" that can be shown on the bottom pane seems to have much more detail to it. I have emaile...
I currently have over 16000 of these messages in my log!! / comments
I currently have over 16000 of these messages in my log!!
I isolated the spgettxhistory calls to Source Gear Vault.
STILL cannot believe you kill my box with the get version calls though. There simply MUST be a way to disable that! / comments
I isolated the spgettxhistory calls to Source Gear Vault.
STILL cannot believe you kill my box with the get version calls though. There simply MUST be a way to disable that!
Here is my engine options settings file in the source control 3 folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!---->
<EngineOptions version="2" type="EngineOptions">
<PollingEnabled>False</PollingEnabled>
<DefaultTraceMinimumInterQueryTimeInMillis>0</DefaultTraceMinimumInterQueryTimeInMillis>
<SysObjectsMinimumInterQueryTimeInMillis>0</SysObjectsMinimumInterQueryTimeInMillis>
<SysTypesMinimumInterQueryTimeInMillis>0</SysTypesMinimumInterQueryTimeInMillis>
<DefaultTraceMinimumRequestedInterQueryTimeInMillis>0</DefaultTraceMinimumRequestedInterQueryTimeInMillis>
</EngineOptions> / comments
Here is my engine options settings file in the source control 3 folder:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<!---->
<EngineOptions version="2" type="EngineOptions">
<PollingEnab...
Thanks for the information. / comments
Thanks for the information.
csmith wrote:
Hi
Deleting the SQL Source Control v2 directory tree without first unlinking the database from SQL Source Control via the user interface would cause the behaviour you describe. Although, it is worth stating that SQL Source Control v3 will work fine with databases with a working base under the v2 folder.
However, if you'd prefer the working base to be under the "SQL Source Control 3" please unlink the database first, delete the unwanted working base folder and link the database again.
Best regards,
Chris
Correct me if I am wrong, but if I unlink the database I lose all historical information, rollbacks, etc, etc, right? This is a flaw in the system if so, and should not be required in any case. Your mandatory uninstall/reinstall to upgrade from V2 to V3 should cover this automatically. / comments
csmith wrote:
Hi
Deleting the SQL Source Control v2 directory tree without first unlinking the database from SQL Source Control via the user interface would cause the behaviour you describe. Alt...
csmith wrote:
Hi
Can you please confirm what you mean by 'associated objects'?
In SQL Source Control version 3 we added Migration Scripts, which must be committed with associated objects. We also enforce changes to be committed together it they are Data and Schema changes related to the same object.
Would you be able to post some brief steps we can take to reproduce the issue?
Many thanks,
Chris
"We also enforce changes to be committed together if they are data and schema changes related to the same object". That is the part I want made optional. When I go to commit a change on a sproc say, I get a popup with numerous other objects already selected and a check box checked to commit all of those other objects I DID NOT SELECT. If I mistakenly just hit enter or continued without UNCHECKING the box I would commit those other objects I did NOT ASK TO BE COMMITTED. / comments
csmith wrote:
Hi
Can you please confirm what you mean by 'associated objects'?
In SQL Source Control version 3 we added Migration Scripts, which must be committed with associated objects. We als...
csmith wrote:
Hi
Just to explain why this behaviour has changed - we had a number of requests to stop ignoring FILLFACTOR and INDEXPADDING by default in the comparisons that SQL Source Control performs. Ignoring these changes is the default option for SQL Compare, but we thought it was a change that SQL Source Control users would generally want to see.
However, what we really want to do is allow the user to configure this setting (as they can in SQL Compare)....
Therefore, we are currently working on adding a comparison options configuration file to SQL Source Control that will allow the user to set FILLFACTOR to be ignored if they so wish.
We are hoping to release this in the next few weeks via our 'Check For Updates' mechanism. I will add a post to this thread when that build is available.
Best regards,
Chris
I to want to see some configuration options in the SSC compare. / comments
csmith wrote:
Hi
Just to explain why this behaviour has changed - we had a number of requests to stop ignoring FILLFACTOR and INDEXPADDING by default in the comparisons that SQL Source Control p...