Saturday, August 27, 2011

Making a ClientDataSet Talk to an MS Access Database 1

I purchased Cary Jensen's book called Delphi in Depth: ClientDataSets a couple weeks ago. It's a great book filled with lots of nuggets. You can only read so much before you need to practice by doing. All of Cary's examples use the DBDEMOS database that comes with Delphi.

So, I have decided to port these examples over so they talk to a MS Access database. I figure this is a great way to learn. For me this is a pain-stakingly slow process, because I want to learn (I mean really learn) how to do this well.

I have just gotten to page 53 of Chapter 3 and decided to blog about what I've done so far.

I substituted the BDE.TTable for a dbGo.TADOTable. I also had to use a dbGo.TADOConnection. The TADOConnection comes with a built in Connection String Builder which works very well.

Anyway, here's where the chicken and the egg thing come into play. In order for this to work you need an MS Access database. So, I created a very simple database using different table names from the DBDEMOS so I can learn how to wire everything up properly.

I set set the TADOConnection.Connected property to true so I can see stuff happening in the IDE. I decided to add a couple more tables to my MS Access database. With my project loaded in the IDE I attempted to open my MS Access database by doubl-clicking on the mdb file... Well, my computer hung. I had to do a hard reboot. Keep this in mind if you go back and forth between Delphi and MS Access.

Another thing that was weird. I tried applying the updates ClientDataSet1.ApplyUpdates(-1); and I got the following error:

So, again Jensen to the rescue. On page 52 he talks about using the ResolveToDataSet property of the DataSetProvider component. I set this property to True and now my updates from with my Delphi application are showing up in the MS Access database.

I'm off to learn some more. I'll share anything that's good to know along the way.

Semper Fi
Gunny Mike

Wednesday, August 24, 2011

I Took A Little Walk-About - But I'm Back

A lot has been going on inside my head since the last post. Delphi has just released XE2. I have finally decided to use ElevateDB for all my Delphi applications. I needed to shit or get off the pot on making a decision about which database to use.

My apps are not that complicated. They are for single user interaction. I originally thought of using MS Access and then ruled that out. Then I toiled with the idea of using some version of MS SQL Server and after careful reading found out that too much stuff has to be configured on the users machine.

I want a simple install, no complicated hunt and grab driver xxx from location yyy followed by asking some weird little question like "did you want to leave the current setting in place". When you sell a $40 app one sales call chews up the rest of the profit.

Anyway, I pursued the idea of using Firebird 2.5 and spent quite a bit of time learning about all the third party vendors who sell Firebird drivers because my Delphi 2010 Professional doesn't come with a DBExpress driver for Firebird. Along the way I learned about the great Delphi community on Stack Overflow ( I also learned how even though Firebird is free, if you want really good help from the people in the know, it will cost you.

So, I said all that to say this... I'm going to use ElevateDB from It's 100% written in Delphi. I'm a small ISV and so is Elevate. The documentation is fantastic. I don't have to pay per incident for answers from people in the know. There is an annual maintenance fee but that's to be expected.

If I could point to one thing that pushed me over the edge in my decision... the demo project used a Delphi "Data Module" to consolidate all the db stuff in one location. I never heard of a TDataModule until yesterday and it came from Tim Young at ElevateSoft. Thank you Tim.

How come Wharton, Biorre and all the others pushing Firebird didn't mention this? Answer they are too busy staring in the mirror they didn't see the big picture.

Semper Fi - Gunny Mike