In my last post1, I wrote that I adopted the FireDAC components [that] work very well in a test harness. Maybe in a simple test, the use of only a TFDQuery is sufficient to query a database and forward data to a grid for display, but in a real program, this component on its own was lacking.
In the main form of the first program that I am converting, I need the following
- The grid should open with data displayed properly (obviously) - the unicode problem.
- Editing a record in a separate dialog box should cause the record in the grid to refresh - but only the one record. There is no need to refresh all the data.
- Clicking on the title bar should cause the grid to be sorted according to the column that was clicked.
- A second click on the same column should cause the grid to be sorted in reverse order (i.e. if before it was in ascending order, then now it should be sorted in descending order).
- After changing the sort, the 'current record pointer' should always be at the beginning of the grid.
- Exiting the program should not cause an error.
Most of the above seems simple to program, but I ran into many "gotchas", some due to FireDAC and some due to the Delphi version (10.2 Seattle). According to CoPilot, many of the bugs that I encountered have been fixed in more recent versions, but I have to learn how to work around them.
As well as consulting CoPilot, I also read the book "Working with FireDAC" by Cary Jensen that I found online a few days ago . I learnt a great deal about ClientDataSets from earlier work of Jensen's, but I haven't learnt too much from this later book. In Chapter 5, he recommends connecting a FDCommand component to a FDTableAdapter that is connected to a FDMemTable that is connected to a datasource component that is connected to the grid (this arrangement is approximately the same with dbExpress components). One enters the SQL command in the FDCommand, opens the FDMemTable and as a result, data is displayed in the grid.
I thought that everything would be fine from now on, but the FDMemTable is not a ClientDataSet and my usage was causing many problems. After a great deal of trial and error, my requirements were met mainly by copying the data from one FDMemTable to another MemTable that is not connected to the FDTableAdapter but is connected to the datasource and grid. In this configuration, the MemTable that is connected to the grid is a local connection, and so deleting data from it (in order to refresh an edited record) does not delete data from the database.
There is a problem with persistent fields and indexes in this copied MemTable; I suspect that the structure of the copied table came from when the table was connected directly to the Command/TableAdapter duo, before it was disconnected from them. This may prove to be a problem in the future, although not insurmountable. With a ClientDataSet I could define indexes on the query when a form opens and these indexes would always be available; with FDMemTable, predefined indexes get deleted every time data is copied to the table (a real bug that has been fixed), so I have to use a more dynamic method. Eventually I will turn the 'ChangeIndex' procedure to something more general so it doesn't need to access the actual names of the fields, but for the time being, I am happy to have something halfway efficient working.
Now that the main form of the program is working, the secondary forms shouldn't present too much of a problem - at least, not from the FireDAC point of view. They will have other problems, I am sure, and entering new data into the program from a file is going to be interesting because of unicode issues.
Internal links
[1] 2065
| Title | Tags | ||
|---|---|---|---|
| 157 | The Goodbye Girl | Films | |
| 446 | Disappointment - Finance exam results | MBA, Finance | |
| 447 | Watching the weight / 4 | Food science, Diet | |
| 1108 | Noise cancelling headphones (2) | MP3, Headphones | |
| 1288 | XML files in Priority | Priority tips | |
| 1712 | TEMU is the new Ali Express | Guitars, Pedal board, Temu |
No comments:
Post a Comment