I’m prototyping a very simple app (long term data with be DB / DB remote) but for now I’m just using local files (CSV / XML / or whatever).
So me thinks good excuse to play with CDSs (been maybe 15years since last used them from scratch) so Drop a TClientDataSource, TDataSource and a TDBGrid on a form - add some fielddefs (in CODE) to CDS and try and open CDS … fails
“Mismatch in Data Packet” is current message - I’ve tried to add a dummy DataSetProvider but no
Normally I’d just used objects and containers and if I don’t find a reasonable answer soon thats what will do - BUT to a non DB person the whole doco (including Google - lots of 15yo stuff) is horrid there is no clear how to use a local CDS from bootstrap
I like the TClientDataSet but these days you should give serious consideration to using the FireDAC TFDMemTable instead.
An application built around TClientDataSet is actually a bit more flexible than one built around TFDMemTable/TFDQuery but the TClientDataSet has been deprecated for a long time now and hasn’t received any updates in many years. Cary Jensen’s TClientDataSet book is probably a good place to start when you’re looking for documentation these days.
Cary also has a FireDAC book which is worth purchasing if you decide to go down the other route instead.
Thanks … its just for a short term solution to data storage which will eventually be server based … I’ve run it up in CDS descendants with specific get and set methods for all data access so if I grow it its a single unit update. So no biggy now.
I’d forgotten about the TFDMemTable I would hope the base doco was better for that - very frustrated that it took an hour or so to find a very straight forward verb - when I have a spare hour I might go the MemTable as that where I’d be going (FireDac) if I scale it - I assume that CDS and FDMT are pretty much 1:1
Alex
Only using it for a prototype … will be using server DBs and as Lachlan suggested I’ll probably swap to some combo of FDMemTables … I was getting away from my day job of maintenance of a 20yo spaghetti pile in Delphi 2009
Realistically could have used TList for all the DB stuff I’m doing (and probably would have been easier) was more of an experiment and tech trial
But all the Data access is encapsulated in a single unit to reworking will be easy