Why the dual representation of data?

• 
  Comparison would be extremely slow for even moderately large files without the .sdcs, just because it takes considerable time to search / randomly access large files - the metadata files are not just a compressed copy of the data, they're a representation of the available indexes so that you can use different comparison keys with the script tables without an enormous performance hit.
  
  Even if we didn't have metadata files, we still wouldn't be supporting free hand-modification of the data for this release - we'd like to get it out sometime this year and getting the parser to handle user-edited files up to our normal quality standards would make this unlikely .
  
  What did you want to do with the data that the .sdcs files / no-hand-editing restriction makes impossible? It might be that we can provide some kind of workaround, or at least we can note it down for a subsequant release.

  Michelle T May 06, 2009 05:52

  - 0 +
• 
  We had 7 different projects for the same product (and database) this year - with a couple being offshore and the rest in-house. Merging code is a challenge, and I could see the ability to merge data from multiple sources as a benefit.
  
  We can work around it by just using the data scripts, and "de-coupling" them, i.e. after modification, we can't use them for comparison. At that point we can create a scratch database if we need further comparisons.
  
  I do like the capability to compare and EXPORT data scripts!

  tbostrup May 06, 2009 09:34

  - 0 +
• 
  We have always maintained schema and data with scripts.
  We implemented a work around when synchronizing data by:
  a) create a new database
  b) synchronize the schema
  c) run "meta-data" scripts (insert statements)
  d) run sql data compare
  
  The dual representation of the data ("meta-data" .sdcs files) does not really make our deployment task easier. We still have to ensure that both files are in sync. We will most likely produce another work around to produce the .sdcs files from the "meta-data" files. But I think we would most likely remain with our current work around.
  
  We would rather take a performance hit and use only the slower "meta-data" scripts.[/list]

  mplan June 16, 2009 10:13

  - 0 +
• 
  I guess my point was well hidden in my last message. The data compare against scripts (that could have been modified) could be useful in a project with multiple branches.
  
  An effective code merge requires 3-way compare. This is understandably not an option in SQL Data Compare. We use Araxis Merge which does a very good job of a 3-way compare and merge. We can use it on the SQL scripts to make desired changes, but it wouldn't work too well with the .sdcs files. At that point, we would no longer be able to compare against the "merged" data scripts, and we'd have to either generate another set of data scripts or create another version of the database for further data compares.
  
  The feature is definitely useful as it is implemented (compare and export data scripts, compare against exported data scripts). Allowing compare against a modifed data script would be even *more* powerful.

  tbostrup June 16, 2009 11:01

  - 0 +
• 
  The .sdcs files are there to complement the .sql files, improving SQL Data Compare's ability to process the files efficiently. If you ignore these files, or even remove them, SQL Data Compare will function correctly, although it will recreate them if they are missing.
  
  I can see no reason why you couldn't perform a 3-way merge on the .sql files. You should be able to ignore the .sdcs files. The only requirement is that the resulting file needs to have each INSERT on its own line.
  
  Please give this a go and let me know if there are issues with this.
  
  Kind regards,
  
  David Atkinson
  Red Gate Software

  David Atkinson June 25, 2009 07:15

  - 0 +

Add comment

Please sign in to leave a comment.