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:
TReader.ReadData is called for the form. It reads the form components,
eventually getting to SQLQuery, and reads the SQL.strings property. At
this point, FParams.ParseSQL is called, which reads the SQL text and
creates the parameters.
The parameter properties are then read, and properties of matching
parameters are set
(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.
(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.)
All this is likely to not be a problem if the sql and parameters are set
at runtime, as one would typically set the database link before the sql
text and parameters. I was originally trying to set up a parent/child
link at design time.
I have not put this in mantis yet, I thought someone might like to check
my analysis - this is my first venture into the component loading code,
and I may be on the wrong track entirely.
cheers,
John Sunderland
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives