Red Gate forums :: View topic - Deployment issue
Return to www.red-gate.com RSS Feed Available

Search  | Usergroups |  Profile |  Messages |  Log in  Register 
Go to product documentation
SQL Comparison SDK Previous Versions
SQL Comparison SDK Previous Versions forum

Deployment issue

Search in SQL Comparison SDK Previous Versions forum
Post new topic   Reply to topic
Jump to:  
Author Message
Waldo2k2



Joined: 21 Aug 2008
Posts: 11

PostPosted: Thu Sep 04, 2008 5:02 pm    Post subject: Deployment issue Reply with quote

I'm having an issue deploying the sdk dll's with our product.

When our program is run from a development machine (which happens to have the full sdk installed) everything works flawlessly.

If we run the program on a machine where only the required red-gate dll's are deployed, something goes wrong.

The licensing seems to work (no prompt or error). However, it seems to skip past synchronizing the schema (I do see a few messages returned about what objects need to be built, but they never actually get built). It skips over the data comparison entirely (most likely because the objects were never built during schema sync).

I'm really at a loss here, here is a list of the files that are being deployed with our application (they reside in the same folder as our dlls, they are not registered in the GAC).
RedGate.Shared.SQL.dll
RedGate.Shared.Utils.dll
RedGate.SQLCompare.ASTParser.dll
RedGate.SQLCompare.Engine.dll
RedGate.SQLCompare.Rewriter.dll
RedGate.SQLDataCompare.Engine.dll

So to recap, it seems to connect to both databases, begin comparing the schema, then just stop for no reason. We receive no error messages at all. None of the database objects are actually built.
This only occurs on deployed installations, it does not happen on the machine that was used to develop the program, which has the Comparison SDK installed.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6678

PostPosted: Thu Sep 04, 2008 5:57 pm    Post subject: Reply with quote

Hi,

On the surface the issue doesn't make a lot of sense.. if the licensing is to blame, the code would throw an exception right at the database registration and never get to the comparison stage.

You may want to open your compiled .NET assembly using reflector and look for the licence in the "resources" section. If the licensing had been done correctly, there would be an <assembly name>.licenses resource inside it and you should see your SQL SDK serial number in there.

If you don't see it, then double-check that you have got a licenses.licx file linked to your Visual Studio project and rebuild it. If you're using an automated build tool instead of building directly in VS please let me know because there may be some extra tasks to add to your automated build to get the licensing to work.

Renaming the assembly will also break the licensing.
Back to top
View user's profile Send private message
Waldo2k2



Joined: 21 Aug 2008
Posts: 11

PostPosted: Thu Sep 04, 2008 6:30 pm    Post subject: Reply with quote

I can verify that the serial is present in my dll (I can see it in notepad even). So I'm not sure it's a licensing issue.
Back to top
View user's profile Send private message
Waldo2k2



Joined: 21 Aug 2008
Posts: 11

PostPosted: Thu Sep 04, 2008 7:04 pm    Post subject: Reply with quote

What's even stranger is that after throwing in some logging to a file, I can see that it in fact did build differences.
It seems to have a message in the Work object for each database object that needed to be created.

So it seems like it's making it all the way to my call to ExecuteBlock...and then failing silently? The whole thing is wrapped in a try catch and it's not raising any exceptions. I can't figure out why this is failing on these machines. They are attempting to sync between the same two databases as the machine that does work...anyone have any bright ideas?
Back to top
View user's profile Send private message
Waldo2k2



Joined: 21 Aug 2008
Posts: 11

PostPosted: Thu Sep 04, 2008 9:33 pm    Post subject: Solution Reply with quote

Well I found what was causing the problem, the good news is that it doesn't have anything to do with the toolkit.

The bad news is that I still don't quite understand why the problem was so erratic.

I have a .net user control that executes the synchronization on another thread so that a progress bar and status message can remain updated. This object is COM accessible and is used inside our application (written in PowerBuilder). The class exposes several events, one of which I called SqlCompiled. All this event does is return the SQL of the executionblock before it is executed...however it seems that this was causing the thread to abort prematurely...I'm not sure if it was because of the size of the string being returned, or just a race-condition, but commenting out the code that raises that event fixes the problem. Go figure.

So I guess the lesson is to log your sql to a file, rather than trying to pass it around all over the place in memory Wink

Thanks for the help, it did help me to stop looking at licensing and deployment as causes of the problem and dig in a little deeper.
Back to top
View user's profile Send private message
Brian Donahue



Joined: 23 Aug 2004
Posts: 6678

PostPosted: Fri Sep 05, 2008 4:03 pm    Post subject: Reply with quote

Thanks for the update. I don't see any obvious reason for this happening, but it may be caused by the script generation -- maybe just returning the ExecutionBlock in your AsyncResult and converting it to a SQL script on the main thread would work?
Back to top
View user's profile Send private message
Waldo2k2



Joined: 21 Aug 2008
Posts: 11

PostPosted: Fri Sep 05, 2008 4:17 pm    Post subject: Reply with quote

Once we finish the mad dash to get this out the door I will try putting it in the asyncresult and see what happens. For now I'm just going to log it to a file.

The more I think about it, this is probably just an issue caused by COM, or more precisely, how PowerBuilder deals with COM (this wouldn't be the first time it's caused me trouble). It may still cause other issues raising the event from the main thread.

Thanks again.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic All times are GMT + 1 Hour
Page 1 of 1

 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group