Comments
Sort by recent activity
aperregatturv wrote:
you mean to say March 2009 right?
Yes :oops:. Thanks for spotting that, I've changed it now [image] .
aperregatturv wrote:
Let me see if i understand the above statement with my situation. We create database using SQL Compare snapshot for version 1 and later we release version 2 with some table/stored procedures and view changes.
SQL Compare 8 will generate a 'change script' which i can run on version 1 database to become version 2 right?
I'm a bit unclear on this as SQL Compare could always generate a change script by comparing any kind of database with a snapshot - the change is that you used to only be able to directly change a script folder, whereas now you can create a change script based on one that can be used on a live database. By 'snapshot' do you mean 'set of scripts'?
In any case, if you have any representation of Version 1 and Version 2 that SQL Compare can read, you can now generate a synchronization script for the differences between them that can be run on a live database, yes. / comments
aperregatturv wrote:
you mean to say March 2009 right?
Yes :oops:. Thanks for spotting that, I've changed it now .
aperregatturv wrote:
Let me see if i understand the above statement with my ...
SQL Data Generator can be used for masking data, but the workflow is somewhat cumbersome - particularly if you have a large SQL Server estate. Having attempted to find various ways to add the feature to SQL Data Generator, we decided that an entirely different product and approach would work better, hence Data Masker.
SQL Data Generator is most useful when you want to generate test data for new development work where you have no previous data to work from, or a smaller project where you are willing to do your own setup for each table individually.
Data Masker is more useful when you have an existing system where you are doing ongoing development work and want to provision realistic data based off your current existing data quickly and easily to your development environment, while making it easier to avoid misusing personal data. / comments
SQL Data Generator can be used for masking data, but the workflow is somewhat cumbersome - particularly if you have a large SQL Server estate. Having attempted to find various ways to add the featu...
SQL Compare doesn't currently treat different parts of a table individually - either the entire table gets synchronized or none of it does. So if you have other changes on the tables you want to synchronize the columns for, those changes will be synchronized as well.
If you're generating a synchronization script for the tables and getting CREATE TABLE statements, this is probably because the tables have some difference which can't be synchronized just with ALTER statements so we have to rebuild it. In the 'Warnings' tab of the synchronization wizard, there should be a warning explaining why we're doing the table rebuild. / comments
SQL Compare doesn't currently treat different parts of a table individually - either the entire table gets synchronized or none of it does. So if you have other changes on the tables you want to sy...
This is problem SDC-857, which we fixed after 7.1.0.245 had gone out. You can contact support@red-gate.com for the updated version with the fix. Sorry for the inconvenience.
(The where clause issue might be a seperate problem - we had some trouble with where clauses starting with certain strings. If you still have where clause problems after you've got the patched version, we'll look into that for you.) / comments
This is problem SDC-857, which we fixed after 7.1.0.245 had gone out. You can contact support@red-gate.com for the updated version with the fix. Sorry for the inconvenience.
(The where clause issue...
You can export CSV difference reports from the Tools menu - they're not as decorative as the SQL Compare HTML reports, but they may do the job - or you may be able to process them yourselves into a format you're happy with?
We experimented with other reporting features in SQL Data Compare but people didn't seem to find them as useful as SQL Compare reports, as there is often a lot more data and it's harder to summarize usefully. / comments
You can export CSV difference reports from the Tools menu - they're not as decorative as the SQL Compare HTML reports, but they may do the job - or you may be able to process them yourselves into a...
If you provide some more information abut the problems that you're having, we might be able to help you out.
A couple of things you might like to try - have you got Data Compare set to disable foreign keys and drop/recreate indexes? If not, setting those options might help. Do you have any check constraints that are being violated by the data you're trying to insert?
Sorry if this advice is a bit simplistic, but without knowing what problems / errors you're experiencing I'm not sure where to aim my investigation [image] . / comments
If you provide some more information abut the problems that you're having, we might be able to help you out.
A couple of things you might like to try - have you got Data Compare set to disable fore...
The main advantage of Changeset is that it will automatically check out only the files which SQL Compare intends to change, just before SQL Compare intends to change them, rather than you needing to check out the entire directory when you want to synchronize to a script folder.
If you're using edit / merge / commit rather than check out / edit / check in, or you don't mind picking which files to check out by hand, or you don't intend to actually change the script folders with SQL Compare, you don't really need Changeset, no.
And it should work with TFS 2008 in the same way as it works with TFS 2005, yes [image] . (You'll need to make sure you have the right MSSCCI Provider installed from the Microsoft website, though.) / comments
The main advantage of Changeset is that it will automatically check out only the files which SQL Compare intends to change, just before SQL Compare intends to change them, rather than you needing t...
I've seen this happen occasionally - if your stored procedures actually have invalid / outdated syntax in them, and sometimes if they refer to objects which have subsequantly been deleted, they won't read back in from the script folder.
The script folder should contain the missing stored procedures if you go and look at it on disk. If those stored procedures wouldn't be able to be created in your database as it currently stands, SQL Compare might be missing them out when it reads in the script folder.
In the next version there will be a much clearer display of what's wrong with any stored procedures that we can't read in from script folders. For now you can turn on logging from the 'icon' menu (the right-click menu for the icon in the top-left of the main program window) and have a look in the log that's created when the script folder is registered, which should give you more idea where the problem might be located.
It might be that our parser is failing to parse actually valid stored procedures - if you think this is happening after taking the steps above, please give us more information about the stored procedures in question (ideally a snapshot / the script folder / a backup of the entire troublesome database sent to support@red-gate.com or michelle.taylor@red-gate.com referencing this forum thread, but we understand this isn't always possible) and we'll look into it. / comments
I've seen this happen occasionally - if your stored procedures actually have invalid / outdated syntax in them, and sometimes if they refer to objects which have subsequantly been deleted, they won...
In general you should be able to just use SQL Compare (without needing SQL Changeset) on databases kept in Subversion repositories, getting the latest version before you load SQL Compare to do the comparison and committing the changes after you're happy with them in your usual way.
SQL Changeset is designed to work with the 'check out / edit / check in' source control model (rather than 'edit /merge / commit' which is the usual way of using Subversion), where you need to check out the files before SQL Compare performs the synchronization.
If you don't need to check out the files before editing them, you don't need SQL Changeset (which mostly just interfaces with Compare to ensure files are checked out during the synchronization process - the only other thing it can do is make sure the latest version is acquired before the comparison, and remind you that files need committing, which aren't really worth such a heavyweight solution on their own). / comments
In general you should be able to just use SQL Compare (without needing SQL Changeset) on databases kept in Subversion repositories, getting the latest version before you load SQL Compare to do the ...
Yes - if you click on the server in the tree on the right hand side, there's a 'Sections to include' section in the preview pane, where you can uncheck 'SQL Script'.
You'll still need to deselect this for every new project, but this will exclude SQL Script for every object in the current project. / comments
Yes - if you click on the server in the tree on the right hand side, there's a 'Sections to include' section in the preview pane, where you can uncheck 'SQL Script'.
You'll still need to deselect t...