Comments
Sort by recent activity
Hi,
The comparison is done by the SQL Data Compare client - so in the case of a live database, it pulls the rows back from SQL Server, and in the case of a backup file, it'll read the contents of the file back to the client app as well. During a comparison, the data is stored on disk in the temporary directory of the machine running SQL Data Compare.
For backup files, the data never goes to SQL Server at all - we read the file directly.
As for speed, I'd recommend using a clustered index as your comparison key if at all possible - it's quite significantly faster when reading backup files.
Hope that helps,
Rob / comments
Hi,
The comparison is done by the SQL Data Compare client - so in the case of a live database, it pulls the rows back from SQL Server, and in the case of a backup file, it'll read the contents of t...
Hi, thank you for your forum post and sorry that you have encountered a problem.
What is the full version number of SQL Source Control you are using?
A support ticket has been created for you: https://redgatesupport.zendesk.com/agent/tickets/81769
Would you please locate the SQL Source Control log file from the period this error occurred? You will find the log files in this path:
C:Users<user_name>AppDataLocalRed GateLogsSQL Source Control
Please attach a copy of the log file to your support ticket or email support@red-gate.com quoting your call reference #81769, with a copy of the log file attached for us to review.
Many thanks,
Rob / comments
Hi, thank you for your forum post and sorry that you have encountered a problem.
What is the full version number of SQL Source Control you are using?
A support ticket has been created for you: http...
Hi there,
We store the messages and attachments on the filesystem, so there's no need for a separate SQL Server (or equivalent) license. It also has the advantage that we can use Microsoft's Indexing Service to provide searching facilities.
We will "single instance" both message bodies and attachments, so if a message has been forwarded from one person to another, only a single copy will be stored, saving space.
Hope that helps,
Robert / comments
Hi there,
We store the messages and attachments on the filesystem, so there's no need for a separate SQL Server (or equivalent) license. It also has the advantage that we can use Microsoft's Indexi...
I might get corrected on this one, but if I remember correctly, this warning is just generated when you perform a sync between two columns, and the destination has a smaller maximum width than the source - such as an nvarchar(10) going to an nvarchar(5).
I don't believe we check explicitly that data will be truncated (since that could be a very expensive operation if the table has a large number of rows), just that there's the possibility of it happening.
Hope that helps,
Robert / comments
I might get corrected on this one, but if I remember correctly, this warning is just generated when you perform a sync between two columns, and the destination has a smaller maximum width than the ...
Assuming "GB" isn't a typo...!
I'm afraid SQL Multi Script needs to load the entire script into memory before executing it. On a 32-bit machine, each process is limited to 2GB of memory space, even if the system has more physical memory installed. [Edit: I've just checked and SQL Multi Script is currently set to run as a 32-bit process, even on a 64-bit operating system, so upgrading to Vista x64 won't help here]
We tested up to about 500MB scripts, if I remember correctly, but that's a couple of orders of magnitude smaller than what you're attempting.
Out of interest, what are you trying to do that results in such a gigantic script? :-)
Thanks,
Robert / comments
Assuming "GB" isn't a typo...!
I'm afraid SQL Multi Script needs to load the entire script into memory before executing it. On a 32-bit machine, each process is limited to 2GB of memory space, even...
Hi,
SQL Server (and hence also SQL Backup) won't automatically shrink files, even though the space is freed up within the file by a log backup. You can manually shrink your log using DBCC SHRINKFILE (http://msdn.microsoft.com/en-us/library/ms189493.aspx), but you should only do this if it's unlikely to grow again in the future.
In an ideal world, your log file will be large enough that it never normally has to auto-grow between log backups, as that will lead to poor performance. The "Best Practices" section of the MSDN article has some sensible advice.
Hope that helps,
Rob / comments
Hi,
SQL Server (and hence also SQL Backup) won't automatically shrink files, even though the space is freed up within the file by a log backup. You can manually shrink your log using DBCC SHRINKFIL...
Hi,
The distribution lists are stored in two files, both located in:
C:\Documents and Settings\[username]\Application Data\Red Gate\SQL Multi Script
Application.dat contains all the distribution lists you've got configured, and Project.sms contains (amongst other things) the actively selected one. I'd advise selecting a different distribution list than the one you want to edit, and exiting SQL Multi Script, before making any changes to Application.dat, or it might fall out of sync.
Note that editing these files by hand isn't something we support, and could end up leaving the application in an "interesting" state, but you should be able to just delete them and get back to a default state if anything does go wrong. Better yet, take a backup of them before doing anything!
Hope that helps,
Robert / comments
Hi,
The distribution lists are stored in two files, both located in:
C:\Documents and Settings\[username]\Application Data\Red Gate\SQL Multi Script
Application.dat contains all the distri...
Hi,
If you've got the Pro version of SQL Data Compare, you can use the command line version to run a compare and synchronisation. The documentation for that is here.
Once you've built up a command line command that'll run the job you want, I'd suggest putting it into a Windows batch file, and scheduling that using Windows' "Scheduled Tasks" feature in Control Panel.
Hope that helps,
Robert / comments
Hi,
If you've got the Pro version of SQL Data Compare, you can use the command line version to run a compare and synchronisation. The documentation for that is here.
Once you've built up a command ...
Hi,
If you're changing a lot of data, yes, this doesn't sound too unusual. The reason for this is that with the default options, SQL Data Compare makes all changes within a transaction. This means that if anything goes wrong, it can roll everything back and leave the database as it was before the attempt.
You can disable the use of transactions in the project "Options" tab - under Synchronization Behaviour, there's an option for "Use transactions in SQL scripts". However, if an operation does fail, the database may be left partially synchronized.
Alternatively, there's documentation on how to shrink a log file that's grown beyond what you'd normally need at MSDN.
Hope that helps,
Robert / comments
Hi,
If you're changing a lot of data, yes, this doesn't sound too unusual. The reason for this is that with the default options, SQL Data Compare makes all changes within a transaction. This means ...
At the risk of this become a thread about graphics editing applications :-), Inkscape is a free vector graphics app that'll happily deal with SVGs, and export as more appropriate things if required as well.
As a sort-of-related aside, it also has a "trace bitmap" feature that lets you scan in hand-scribbled diagrams of whatever, and turn them into a cleaner vector representation. I've used it quite a bit when I've wanted to put the results of a whiteboard scribbling somewhere a little more permanent.
Cheers,
Rob / comments
At the risk of this become a thread about graphics editing applications :-), Inkscape is a free vector graphics app that'll happily deal with SVGs, and export as more appropriate things if required...