Comments
Sort by recent activity
Thank you for your post in the forum.
Unfortunately you cannot configure the engine logging through the Command Line.
The engine logging can only be configured via the SQL Data Compare GUI and the level of logging set via the GUI will apply to any subsequent GUI and Command Line comparison / synchronizations.
Many Thanks
Eddie / comments
Thank you for your post in the forum.
Unfortunately you cannot configure the engine logging through the Command Line.
The engine logging can only be configured via the SQL Data Compare GUI and the ...
Thank you for your post into the forum.
Does this error every time you attempt to bring up the candidate list?
Does this error occur within SQL Server Management Studio or within Visual Studio?
Can you please try to delete the existing cache by navigating to SQL Prompt--> Cache Management and delete all the cache and open and new query window which will recreate the cache?
Many Thanks
Eddie / comments
Thank you for your post into the forum.
Does this error every time you attempt to bring up the candidate list?
Does this error occur within SQL Server Management Studio or within Visual Studio?
Can...
Thank you for your reply.
Are you using or have enabled the Data Dude or Visual Studio Team Edition for Database Professionals?
I ask this question, as I found a previous forum post with the same exception as the one you are experiencing and SQL Prompt does not support Data Dude / Visual Studio Team Edition for Database Professionals.
You can read the previous post by using this LINK.
Many Thanks
Eddie / comments
Thank you for your reply.
Are you using or have enabled the Data Dude or Visual Studio Team Edition for Database Professionals?
I ask this question, as I found a previous forum post with the same e...
Thank you for your reply and sorry for the delay in replying back to you.
I suspect that SQL Compare treats persisted computed columns as if they are actual table columns. So rather treat them as a special case, it is easier for SQL Compare to perform the rebuild instead of the drop / add.
Many Thanks
Eddie / comments
Thank you for your reply and sorry for the delay in replying back to you.
I suspect that SQL Compare treats persisted computed columns as if they are actual table columns. So rather treat them as ...
Hi Jason
SQL Compare will in most circumstances attempt to alter an existing table when synchronizing a database.
This LINK is to a knowledge base article explains the circumstances as why SQL Compare will rebuild a table.
I hope this article answers your question.
Many Thanks
Eddie / comments
Hi Jason
SQL Compare will in most circumstances attempt to alter an existing table when synchronizing a database.
This LINK is to a knowledge base article explains the circumstances as why SQL Comp...
Thank you for your reply.
Hopefully the following information may provide some more help to you.
You can alter the Seed in the Column Generation settings. In the 'Tables to populate' list down the left hand side, you can expand each table to see the columns that make the table.
Select a column so that it highlights in yellow and the Column generation settings will be displayed
By default, every column has a different seed. The seed for the first generated column of the first table in the Tables to populate list is 0; for each subsequent generated column in that table, the seed is increased by 1. For the second table, the seed value starts at 1025, and so on.
You can alter the seed value and generate values that are shuffled, to produce a different set of results.
Many Thanks
Eddie / comments
Thank you for your reply.
Hopefully the following information may provide some more help to you.
You can alter the Seed in the Column Generation settings. In the 'Tables to populate' list down the...
Thank you for your post into the forum.
You are correct that SQL Data Generator is not aware of the current data in the table. However, there is no need to load several Data Generator projects.
If I have understood you correctly, you wish make several tests loading 1000 rows of then increasing to 2000 then to 3000.
There is an option which by default is enabled, 'Delete data from table before generation'. You will see this option immediately underneath where you specify the number of rows to be generate.
So you load the single or create a new SQL Data Generator project. Load 1000 rows of data, by default Data Generator will select 50 rows. Generator the data.
Repeat the data generation specifying 2000 rows and ensure that the 'Delete data from table before generation' option is checked or enabled.
I hope this answers your question.
Many Thanks
Eddie / comments
Thank you for your post into the forum.
You are correct that SQL Data Generator is not aware of the current data in the table. However, there is no need to load several Data Generator projects.
If...
Hi Chris
If you wish to create your backup files using a single thread, do not need to specify the THREADCOUNT = keyword in your existing backup scripts. When SQL Backup peforms the backup and the THREADCOUNT keyword is not specified it will create or perform the backup using a single thread.
In my previous post to this topic, I wanted to make you aware of a slight change that could easily be missed when using either the Backup or Schedule Backup Job Wizards via the SQL Backup GUI. In that SQL Backup V6 the option to multiple threads is now enabled by default where in previous versions it was disabled.
Many Thanks
Eddie / comments
Hi Chris
If you wish to create your backup files using a single thread, do not need to specify the THREADCOUNT = keyword in your existing backup scripts. When SQL Backup peforms the backup and the...
Hi Chris
The amount of continuous memory in the MemToLeave SQL memory space has remain unchanged from SQL Backup V4 through to the current latest Version 6.3.
The amount of continuous memory is currently 6x MAXTRANSFERSIZE value x the number of threads.
By default the MAXTRANSFERSIZE value is approximately 1MB.
So for a single threaded backup, 6MB of continuous memory has been required.
However the has been one change that is easily missed when configuring new backup tasks using either the backup wizard or scheduled backup jobs wizard.
In SQL backup V4 and V5, the option to perform a multi-threaded backup is turned off by default.
In SQL Backup V6, the option to perform a multi-threaded backup is turned on by default and the value set is determined by the number and type of CPU installed on the machine.
If you had existing backup jobs, after upgrading to SQL Backup V6 these jobs thread settings will remain unchanged. So if your job uses a single thread it will continue to use a single thread.
I hope this helps.
Many Thanks
Eddie / comments
Hi Chris
The amount of continuous memory in the MemToLeave SQL memory space has remain unchanged from SQL Backup V4 through to the current latest Version 6.3.
The amount of continuous memory is cur...
Hi
Thank you for your post into the forum.
Yes it is possible to backup a database on a production server and restore the backup file on another server. Both databases will require that the SQL Backup Servers components are installed upon them.
Use either the 'Backup' wizard or if you wish to schedule a backup use the 'Schedule Backup Job' wizard on the production machine to the create the job or the backup file.
To restore the backup file created on the other machine, run the 'Restore' wizard to restore the file.
This link is to the SQL Backup help information on the Red Gate web site: SQL Backup Help.
You will find various help information, demos and walkthroughs on how to use SQL Backup.
Many Thanks
Eddie / comments
Hi
Thank you for your post into the forum.
Yes it is possible to backup a database on a production server and restore the backup file on another server. Both databases will require that the SQL Ba...