Firebird date fields, continued

Following on from my previous post, I discovered that the code which I posted did not work.


What did work was a query with parameters:

update person set
dob = :a1, examdate = :a2
where id = :an

Here is the corresponding program code

with qDates do
 begin
  close;
  parambyname ('a1').asdate:= dob;
  parambyname ('a2').asdate:= examdate;
  parambyname ('ap').asinteger:= pid;
  execsql;
 end;

It's nice to know that this blog is being read by someone (see comment attached to previous post), and it's even better to know that we reached the same conclusion.

At the moment, the code which enters a new person into the database is split between two queries: one is an insert query, passing string literals, and the other (shown above) is an update query passing parameters. I now wonder whether it is possible to use only one query, which will insert using parameters. This will make the code run quicker and will also be clearer. Early days.

The port of the simple program from BDE to FB was completed last night with the above code. It's interesting to draw conclusions from the port:

1. One unit reads a text file (which is the output from the exam program), and inserts data into the 'people' and 'results' table. This is done using the TSQLQuery component with 'insert' and 'update' statements (should only be 'inserts' - I'll work on this tonight).
2. One unit allows the 'people' data to be edited - this is done at the moment with the trinity of TSQLDataSet, TDataSetProvider and TClientDataSet. Now that I think of it, one needs the 'trinity' only when a bi-directional dataset is needed, and in this case I am displaying only one record, which means that I may be able to use the TSQLQuery alone, in the same way that I used TQuery in BDE programs.
3. One unit displays all the people who have taken the exam - as this uses a dbgrid, the trinity is used.
4. Two units output data (to Word) - TSQLQuery.

So, apart from correcting the input unit (a simple matter), I should investigate whether the editing unit can be simplified.

One final 'gotcha': in order to use the program during development, the TSQLConnection has the appropriate database string and is automatically opened. This has to be changed after primary development has been finished, as the program must be deployed without a database string, meaning that the connection must be initially closed. I can't see a way of doing this automatically; I will have to remember to change the connection parameters before deploying the program.