Op donderdag 24-01-2008 om 00:09 uur [tijdzone +1100], schreef John:
> 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.
Huh? Are you sure? Did you recompile everything correclty?
> >> (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)
> >
> 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 ?
Yes. Despite there's no difference in parameter style, there is a
difference in the ConnOptions.
Joost.
_________________________________________________________________
To unsubscribe: mail [EMAIL PROTECTED] with
"unsubscribe" as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
