I have a basic editable connection working now, but there remain a
number of questions:
1) When I tried editing in a dbGrid, I had trouble with the field
length. Looking through the code, I can't see anywhere where the length
of a string is checked against the length of the field, and longer
strings appear to overflow the field / record buffer. Should this be so
? I can fix the problem by doing the edits with a dbEdit control with a
specified maximum length, but I can't find anything in the dbGrid
component to do this. (I presume it would really be the TColumn
component)
My real question is, should it be the data control be doing it, or
should the sql components truncate a string that is too long ?
2) I am now trying a simple master slave form, with the slave table
having a "parent" field which links to the primary key (a sequence
generated number) in the master table. I can make this work with an
After Scroll Event on the master table thus:
with sqlAC {TSQLQuery component selecting from slave table} do begin
active := false;
Params[0].AsInteger := sqlPars.Fields[0].AsInteger; {sqlPars is on
the master table}
active := true;
end;
Is there anything less drastic than closing and reopening the sql that
will refresh the query with the new parameter values ?
I tried to do this by setting the datasource on the above SQL, (and
masking the AfterScroll event), but kept getting "field not not found"
errors. Should this work ? (I had the parameter name matching the
field name I was trying to link to. The field is only called "ref", so
there is not a lot of room for typos, and yes I checked for the correct
case!)
3) Recently Joost van der Sluis wrote:
You could solve this problem by setting the update/delete/insert queries
yourself. (and set parsesql to false)
When I set ParseSQL to False, the object inspector in Lazarus says
"updating is only possible if ParseSQL is true" - unless I make it
readonly, which defeats the purpose.
Looking through the code, I surmise that when the query is opened,
InternalOpen calls Prepare which in turn calls ParseSQL, but that
ParseSQL exits after only getting the statement type if ParseSQL is
false. If the statement is a "select" statement and if it is
updateable, then InternalOpen initialises the update queries. If SQL
text is supplied, it is assigned to the queries, otherwise they are left
blank. When ApplyUpdates is called, this calls ApplyRecUpdate for each
record, and this then either runs the supplied SQL, or, if the supplied
SQL is null, generates it own SQL (using the stuff stored by Parse SQL) .
Is this basically correct ? (If so, you might see some of this expanded
a bit into some documentation)
If so, I guess leaving ParseSQL=true will waste some processing time,
but not actually stop it working.
Any hint about the structure of the code for the update queries ? I
guess I can work them out looking at what ApplyRecUpdate is trying to
generate, but an example would make life easier.
4) I still haven't been able to set a breakpoint in, or trace into any
of the sqldb code. Is there any good reason for this ? I can do so in
other library units, "buttons" for example. (If I could work this out,
I might be able to answer a more of the other questions for myself)
Thanks for your patience,
John
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
