Getting Started documentation

Wiki
1

(I’m not sure if “Wiki” is a good category for this. Certainly, “non-tech” and “Test” don’t seem to fit. Feel free to modify.)

I’m new to DataAbstract. I’m in love with the concept, I’ve looked at the examples, and the tools. I went ahead and bought a license. However, had to put it aside because my first experiences weren’t optimal.

I really think that DA needs a good document to get started that covers not only DA and RO SDK concepts and architecture, but also expected practices and work flow. What I mean by this is: I have an application that is pretty much classic Delphi, with data sources and data aware controls all over the place. The closest I have to delegation is a centralized data module, and methods to get instantiated objects from the database (all coded by hand.)

I think I’m hardly the only one to have an active project that was written like this.

I suffer from framework envy. That’s why I bought a DA license. The thing is, it is gathering bit dust in my hard drive. I’m not using it because I don’t know how to. The existing documentation is telling me is that I need to start over, that it is too difficult to do otherwise.

So, I’m resorting to the community. Do you have experience moving from a classic Delphi DB application to DA? Do you want to share your knowledge with the rest of us?

I’m not asking for a step-by-step kind of thing. General advise and a couple of study cases would be great. What previous steps would you take? How to refactor your application in order to be able to “plug in” DA afterwards?

What I’ve been doing for the past months is to looking every place in my application where a direct reference to database objects are being used (queries, tables) and replacing them with plain data sources instead, and setting them up when needed in code. But I’m still missing a step between in my “refactor” - … - “plug in DA” - “profit!” four step plan…

So, what was your experience moving to DA? Did you start over? Did you carefully planned a migration path? What kind of plan would you create if you had to do it again? Any piece of advise (links, case stories, whatever) would be welcome.

2

Hello Leonardo,

I think you raise a good point. Architecturally there are differences. Depending on the complexity of your client SQL you will ether need to move the SQL to the middle tier (if it is very complex) or convert it to DA SQL.

Are you using Relativity or a custom middle tier? How many tables and queries do you have in your client?

I actually haven’t tried to migrate an existing client application to DA, but I think it would be a good thing to try.

I’ll look into the documents like you suggested, as well as a general guide for converting.

Thanks!

–
Jim McKeeth
Developer Evangelist
RemObjects Software
jim@remobjects.com

3

“Middle teeers? We don’t need no stinkin’ middle teeers!”

Actually, this is a basic application. It is not big at all, no middle-tier, just a simple client-server application. I’m using AnyDAC for database access. I think is just about thirty tables, tops.

Any ideas on how to get things going, in order to start using DA?

4

Hi Leonardo,

I think the best way to migrate your app to DA is to isolate all your DB activity (I guess you did that already), then add a datamodule, add the “middle tier components” like SessionManager, ConnectionManager, LocalDataAdapter and go from there.
Then you can replace your TTable, TQuery components by TDAMemDataTable.

Best way to see how it all works is to create a new (dummy) DA VCL application. When the wizard shows, choose the “Two tier (client/server) option” and go from there.

Hope this helps.

Regards,

Filip.