Crash as synchronisation wizard starts

CrispinH

I've managed to crash SQL Data Compare at the start of a Sync Wizard operation. It's a bit odd because I have two development servers with this database on which I'm comparing to a single production server. The only difference (according to SQL Compare) between the two development servers is a login which exists on one but not the other. The login shouldn't be relevant because I'm using Windows authentication for the sync operations.

The development server with the login will synchronise, but the the other one won't and falls over.

The error is complaining about null data. The trace is:

System.Data.SqlTypes.SqlNullValueException was unhandled
Message="Data is Null. This method or property cannot be called on Null values."
Source="System.Windows.Forms"
StackTrace:
Server stack trace:
at System.Data.SqlClient.SqlBuffer.get_String()
at System.Data.SqlClient.SqlDataReader.GetString(Int32 i)
at _31._1()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
at _33._1(IAsyncResult )
at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage msg)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Robert C

Hi,

Sorry about that - it's a known issue which affects some SQL Server 2000 servers with SQL Data Compare 6. We've fixed it in version 6.1, which should hopefully be released in the next few weeks.

Sorry for the inconvenience,
Robert

Robert C

Hi,

Just to let you know, 6.1 is now out. You can get this by going to Check for Updates on the Help menu.

Robert

CrispinH

Robert

I hate to say it but things seem to have got worse with 6.1. The crash problem I was experiencing involved SQL Server 2000 databases, but now I'm having a general problem (ie including SQL Server 2005 developer and Express editions) with SQL Data Compare 6.1. To see if it was my PC causing the problem I installed SQL Data Compare 6.0, then 6.1 on a reasonably clean Virtual Machine as well and ran into the same problem.

I've also tried to revert to 6.0 but that no longer works properly either.

Any ideas for a fix? It's suddenly got a bit critical as I now rely on being able to compare DBs.

Regards

Crispin

Robert C

Hi,

We've just identified another issue there which didn't get caught in 6.1, unfortunately. However, this time there is a workaround which should get you going again.

If you have a look in the registry of the target (destination) SQL Server, you should find a key at HKEY_LOCAL_MACHINE\Software\Microsoft\MSSQLServer. Within that key, if you could create a string value named "BackupDirectory", and with a value of your default backup directory for that server, then hopefully that should get Data Compare running again.

If you're comparing to a named instance as the target server, then the key will be in HKEY_LOCAL_MACHINE\Software\Microsoft\Microsoft SQL Server\<instance identifier, like MSSQL.1>\MSSQLServer instead.

The BackupDirectory value exists in almost all cases, but for some reason some machines occasionally seem to be missing it.

We've fixed the bug internally, so the next release will obviously not need this workaround.

Hope that helps,
Robert

CrispinH

Hi Robert

Thanks for the response. I had a go with the workaround but it didn't work for me. The default instance on th target machine is SQL Server 2005 developer edition and there is also an instance of SQL Server 2005 Express. In the past there were SQL Server 2000 instances but these have gone now.

I tried adding the value in the appropriate location with and without a trailing backslash just in case that made a difference - it didn't. I also added this value to both apparent instances of SQL Server.

The exported values are:

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer]
"BackupDirectory"="D:\\SQL Server data\\2005 instance - Developer\\Backups\\"

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSSQLServer\MSSQLServer]
"BackupDirectory"="D:\\SQL Server data\\2005 instance - Developer\\"

Crispin

Robert C

Hi,

Thanks for the reply... bother, I thought that would work! Could you confirm the type of exception and stack trace you're getting with 6.1? I'm pretty sure it won't still be the SqlNullValueException you saw in 6.0, but it's worth checking...

Thanks,
Robert

CrispinH

Hi Robert

Sorry for the delay. Here's the exception detail.

System.InvalidCastException was unhandled
Message="Specified cast is not valid."
Source="System.Windows.Forms"
StackTrace:
Server stack trace:
at L.a()
at System.Runtime.Remoting.Messaging.StackBuilderSink._PrivateProcessMessage(IntPtr md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.PrivateProcessMessage(RuntimeMethodHandle md, Object[] args, Object server, Int32 methodPtr, Boolean fExecuteInContext, Object[]& outArgs)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
Exception rethrown at [0]:
at System.Windows.Forms.Control.MarshaledInvoke(Control caller, Delegate method, Object[] args, Boolean synchronous)
at System.Windows.Forms.Control.Invoke(Delegate method, Object[] args)
at System.Windows.Forms.Control.Invoke(Delegate method)
at N.a(IAsyncResult )
at System.Runtime.Remoting.Messaging.AsyncResult.SyncProcessMessage(IMessage msg)
at System.Runtime.Remoting.Messaging.StackBuilderSink.AsyncProcessMessage(IMessage msg, IMessageSink replySink)
at System.Runtime.Remoting.Proxies.AgileAsyncWorkerItem.ThreadPoolCallBack(Object o)
at System.Threading._ThreadPoolWaitCallback.WaitCallback_Context(Object state)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallbackInternal(_ThreadPoolWaitCallback tpWaitCallBack)
at System.Threading._ThreadPoolWaitCallback.PerformWaitCallback(Object state)

Hope this helps. I need to be able to run a sync soon - will you be issuing a hotfix or something?

Regards

Crispin

Robert C

Hi Crispin,

Thanks for the reply - that's confirmed that it's the bug we thought it was. We're aiming to get a patch some time next week, as soon as we've got it tested.

If you'd be willing to give a pre-release build a test to make sure we've fixed the problem for you, then that would be great. If so, drop me an email at robert dot chipperfield at red-gate dotcom, and I'll get one out to you as soon as we can.

Many thanks,
Robert