Comments
Sort by recent activity
Not sure if it comes into play, but could file zeroing be a thing here? Would Instant File Initialization be helpful if so?
Other than that, I would say it is VERY dependent on your IO read, network, IO write capabilities and latencies - which can each be a HUGE impediment to throughput. / comments
Not sure if it comes into play, but could file zeroing be a thing here? Would Instant File Initialization be helpful if so?
Other than that, I would say it is VERY dependent on your IO read, networ...
You do not move the data multiple times when you use SQL Clone. One move to create the image (from a backup or directly from a live database). Then it is just "mounting" that image as a new read/write database on any SQL Server. Each time you do this it takes 10-15 seconds and ~50MB of local disk space.
Now, if you actually ACCESS data (say for tuning some query or running some report) then you move the data to the local box. Thus the network becomes much more important piece of the infrastructure pie (as does the storage you create the image on). / comments
You do not move the data multiple times when you use SQL Clone. One move to create the image (from a backup or directly from a live database). Then it is just "mounting" that image as a new read/wr...
I agree with Grant, but with a rather large caveat. The query plan you get is drastically influenced by the "server" capabilities. In the vast majority of cases the machine you mount a clone on will be a fraction of the hardware (especially the optimizer-affecting ones of CPU and RAM) that the production box is. So you could wind up chasing a red herring or worse. Another potential gotcha is the edition/version/build of SQL Server the clone is mounted on. / comments
I agree with Grant, but with a rather large caveat. The query plan you get is drastically influenced by the "server" capabilities. In the vast majority of cases the machine you mount a clone on wil...
Please add me to the list of people who are requesting that you allow for complete user control of the locations where prompt stores all of it's information. / comments
Please add me to the list of people who are requesting that you allow for complete user control of the locations where prompt stores all of it's information.
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...