SQL Data Compare switches culture and not switches back

• 
  Thanks for your post.
  
  Are you refering to the date format setting at the start of the script?
  
  SET DATEFORMAT YMD
  GO
  
  If so, then this is just the dateformat for the session and will only be used for this one script. It doesn't need to be set back afterwards as it is only used for the session.
  
  This session setting was added to the script in SQL Data comapre 8, to get round a problem where the dateformat for certain cultures wasn't properly scripted.
  
  I hope this helps explain.

  Chris Auckland April 08, 2010 07:56

  - 0 +
• 
  Hi Chris
  
  No, I don't mean the SQL Server script, I mean the .NET assemly thread culture 'Threading.Thread.CurrentThread.CurrentCulture'.
  At the start of the program, the culture of 'Threading.Thread.CurrentThread.CurrentCulture' is set to 'de-CH', and when I pass the follow code block
  

  01: Dim db1 As New Database
  02: db1.RegisterForDataCompare(New ConnectionProperties(ssDBServerName, ssDBName, ssDBUsername, ssDBPassword), Options.Default)
  03:
  04: Dim db2 As New Database
  05: db2.RegisterForDataCompare(New ConnectionProperties(sdDBServerName, sdDBName, sdDBUsername, sdDBPassword), Options.Default)
  06:
  07: Dim mappings As New SchemaMappings
  08: mappings.CreateMappings(db1, db2)
  09:
  10: Dim session As New ComparisonSession()
  11: session.CompareDatabases(db1, db2, mappings)
  12:
  13: Dim provider As New SqlProvider
  14: Dim block As ExecutionBlock.ExecutionBlock = provider.GetMigrationSQL(session, True)
  15:
  16: Dim executor As ExecutionBlock.BlockExecutor = New ExecutionBlock.BlockExecutor
  17: executor.ExecuteBlock(block, sdDBServerName, sdDBName, False, sdDBUsername, sdDBPassword)
  

  
  
  then the culture of the assembly thread 'Threading.Thread.CurrentThread.CurrentCulture' has changed on execute 'CompareDatabases' in row '11: ...' to 'invariant culture'.
  
  After that, the assemlby thread has an invalid culture to continue work, which will not set back by RedGate components.
  
  
  Can you tell us why this appears?
  
  Regards,
  Demian

  knoxi April 08, 2010 09:45

  - 0 +
• 
  Thanks for your clarification.
  
  I've been able to reproduce this now, so I've logged it as a bug with the API (CSD-127).
  
  As a workaround for the time being, you could reset the culture immediatly after CompareDatabases e.g.
  
  System.Threading.Thread.CurrentThread.CurrentCulture = new System.Globalization.CultureInfo("de-CH");
  
  I hope this helps.
  
  I'll let you know if we get a patch out that fixes this problem.

  Chris Auckland April 12, 2010 05:49

  - 0 +
• 
  Hi Chris
  
  Thanks for your feedback.
  
  We have already implemented this workaround. But it would be better to solve it with fixed components.
  
  Thanks for your efforts.
  
  Regards,
  Demian

  knoxi April 12, 2010 11:08

  - 0 +
• 
  Hi Demian,
  
  This is now fixed in the latest SQL Data compare engine.
  
  You can download the patch for SQL Data compare here.
  
  Or the updated SDK with the new SQL Data compare engine here.
  
  I hope this helps.

  Chris Auckland May 13, 2010 04:55

  - 0 +
• 
  Hi Chris
  
  It is fixed in this release:

  Or the updated SDK with the new SQL Data compare engine here.

  
  but not in the release here:

  You can download the patch for SQL Data compare here.

  
  Regards,
  Demian

  knoxi June 02, 2010 07:48

  - 0 +

Add comment

Please sign in to leave a comment.