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.