Joost van der Sluis wrote:
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?
It does, in so far as the parameter specs are now retained, but now the
database property of sqlquery is not read, so it still can't work
properly. In fact, I can't even set the database from the Lazarus
object inspector.
(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.
If OnChangeSql doesn't care what sort of database it is connecting to,
why is it necessary to call OnChangeSQL to from SetDatabase even though
the sqltext hasn't changed ? Would it be sufficient to just unprepare
it ? I guess not, you still want some of the other effects of running
OnChangeSQL. I wondered about putting the contents of OnChangeSQL into
another (private) function, and passing it a parameter as to whether the
SQL had really changed (=> DoCreate must be true) or not. Then
OnChangeSQL could call NewFunction(True) and SetDatabase could call
NewFunction(false), and NewFunction would pass the parameter into
DoCreate when it called Fparams.ParseSQL. In this case, does
SetDatabase really need the call to Fparams.ParseSQL ?
Thanks,
John Sunderland
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
