Bad Handshake and LLBLGen 1.1

Posts   
 
    
scotru
User
Posts: 104
Joined: 16-Feb-2006
# Posted on: 25-Jul-2012 08:33:46   

Ok, I know that LLBLGen 1.1 is very old at this point. But I have a large project developed in it and with plans for the new version to use a different data access model it doesn't make sense to invest the time necessary to migrate this code to newer version of LLBLGen. Plus it's working well--or was until I encountered the dreaded "Bad Handshake" error with versions of MySQL 5.5.12 or greater or 5.1.54 or greater.

Now, I know that error is caused by a bug in DevArt/CoreLabs provider and is outside of LLBLGen's pervue. But my question is this--is it possible to make the latest DevArt driver (6.x) work with LLBLGen 1.1? If so, would I need to rebuild the MySQL DQE to link against the newer DevArt driver? Or could I do this with a manifest file?

I'm also asking this question of DevArt, but I appreciate any help or suggestions for getting started that might be provided here.

Thanks!

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 25-Jul-2012 10:15:33   

It's possible to rebuild the MySql DQE against the devart assembly, you have to do some refactoring to the MySQL DQE code but it should work. You have to sign the assembly again, so the signature changes so your application's references have to be updated to reference the updated MySQL DQE.

May I ask what 'different' data access model you're moving to and why LLBLGen Pro v3 can't handle that?

Frans Bouma | Lead developer LLBLGen Pro
scotru
User
Posts: 104
Joined: 16-Feb-2006
# Posted on: 25-Jul-2012 15:42:35   

Hey Otis,

Thanks very much--I will give this a try. So to recap, what I need to do is rebuild the MySQL DQE from the provided source, but linking to the new 6.x dotConnect (you indicate some refactoring may be required here--are their specific areas I should be aware of?) Then rebuild my project linking to the new DQE.

As for the future, I may very well use LLBLGen 3 in some form for the new model--the changes we are looking at are based on 2 main goals:

1) We want database independence, so if we do use LLBLGen we'll be switching from Self-Servicing to Adapter based.

2) We're looking at moving to a server side service based model to try to decouple the client further from the database rather than accessing the database directly from the client as we have been doing. We'll be likely be consuming JSON or XML or some such thing in the client.

The biggest problem I have with continuing to use LLBLGen generated classes to directly consume data from the database is my need to support more platforms. I want to be able to reuse the same data interface layer on iOS and Android as is used by my desktop .NET client. I don't want to have to maintain multiple code bases (I use Xamarin so it's all C#/.NET). Since LLBLGen is not available on these mobile platforms (or more specifically the providers LLBLGen supports are not available), we'll have to do something else in the client here. But as I say, I may very well still use LLBLGen on the server side.

We're also looking at moving more of the business logic to the server to simplify maintenance so the API the client consumes may look very different than the current client's .NET data layer.

So all in all, I hate to spend a lot of time trying to migrate this client data layer when it will all probably go away anyway and be replaced by something that looks very different on the server side.

If you (or others) have suggestions on better ways to accomplish these goals, I'm definitely open to them too. Nothing is set in stone at this point.

Walaa avatar
Walaa
Support Team
Posts: 14946
Joined: 21-Aug-2005
# Posted on: 25-Jul-2012 19:18:52   

You can have LLBLGen as your DAL on the server, and then you can send out XML or JSON, to be consumed by clients of different platforms. A webService would a good choice to use on the server side in this case.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39588
Joined: 17-Aug-2003
# Posted on: 26-Jul-2012 11:10:49   

Indeed. With v3.5, you can create a WCF Data Services service with llblgen pro which exposes OData, which is an industry standard and which is supported on many platforms (see http://odata.org) You can switch the WCF Data Services service to export JSon instead of XML at the WCF level. On the server side, you have .NET / llblgen pro with linq as you would when you opted for EF and WCF Data Services.

It's the easiest way to set up a service without much work and expose a service API

Frans Bouma | Lead developer LLBLGen Pro