Op woensdag 23-01-2008 om 10:28 uur [tijdzone +1100], schreef John:
> John wrote:
> > Hi,
> >
> > Environment: win32, Lazarus SVN 13347, fpc SVN 9468
> >
> > In Lazarus, I have a simple query that uses a parameter: select *
> > from test_cld where code = :code;
> > I am defining it at design time using the object inspector. I set the
> > property parameters to ftString and ptInput, save everything, and
> > close the form, and open it again.
> >
> > If I view the lfm source, it get:
> >
> > Params = < item
> > DataType = ftString
> > Name = 'code'
> > ParamType = ptInput
> > end>
> >
> > as expected, but in the object inspector, the datatype and Paramtype
> > are back to ftUnknown and ptUnknown.
> >
> > Further, even if I fix them and run the app, I get an error 'unknown
> > field type for parameter "code"', which implies that the same thing is
> > happening. (With the correct values in the parameter I can open the
> > query at design time).
> >
> > I can't find any reference to this in mantis - has anyone else had the
> > problem ?
> I posted this about a month ago. After much tracing, adding debug
> lines, (and general chasing of wild geese,) it appears to me that the
> following is happening:
> (So far so good)
>
> At the end of TReader.ReadData for the form, DoFixupReferences is called.
> This sets the database to which the SQLQuery is attached by calling
> TCustomSQLQuery.SetDatabase, which:
> Calls TCustomSQLQuery.OnChangeSQL, which:
> Calls Fparams.ParseSQL(FSQL.Text,True, ........,psInterbase)
>
> However, the second parameter, "true" tells Fparams.ParseSQL to
> "DoCreate", which means dropping all the existing parameters and
> recreating them from the sql text. This means that the param field type
> is lost, as the new parameters are created with ftUnknown.
Can you try if the attached patch fixes this?
> (Note also that the parameters are always created as psinterbase type
> params. I am not sure if this causes a problem, as it may be
> overwritten somewhere, but it looks strange as there is a 'case' in
> ParseSQL to cover the different types of parameter styles.)
That's no problem, since the parameter style is only used to re-write
the query in a format which the db-engine understands. The call to
ParseSQL in OnChangeSQL doesn't use this result from the ParseSQL
function. (The code is runned, though. So there is room for a
optimization here)
Joost.
Index: sqldb.pp
===================================================================
--- sqldb.pp (revision 9878)
+++ sqldb.pp (working copy)
@@ -773,13 +773,16 @@
begin
if assigned(value) and not (Value is TSQLConnection) then
DatabaseErrorFmt(SErrNotASQLConnection,[value.Name],self);
- UnPrepare;
- if assigned(FCursor) then TSQLConnection(DataBase).DeAllocateCursorHandle(FCursor);
- db := TSQLConnection(Value);
inherited setdatabase(value);
- if assigned(value) and (Transaction = nil) and (Assigned(db.Transaction)) then
- transaction := Db.Transaction;
- OnChangeSQL(Self);
+ if not (csLoading in ComponentState) then
+ begin
+ UnPrepare;
+ if assigned(FCursor) then TSQLConnection(DataBase).DeAllocateCursorHandle(FCursor);
+ db := TSQLConnection(Value);
+ if assigned(value) and (Transaction = nil) and (Assigned(db.Transaction)) then
+ transaction := Db.Transaction;
+ OnChangeSQL(Self);
+ end;
end;
end;
