Re: [lazarus] sqldb query parameter properties not loaded?
Joost van der Sluis wrote:
Op donderdag 24-01-2008 om 20:56 uur [tijdzone +1100], schreef John:
Joost van der Sluis wrote:
Op donderdag 24-01-2008 om 00:09 uur [tijdzone +1100], schreef John:
Snip
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?
You won't often catch me saying Yes I am *sure* I compiled everything
correctly ! I think I did, though.
Quick test is to add a new writeln, see if it is triggered. If so you
have rebuild it properly.
This is my version of set database:
It doesn't contain a call to Inherited.SetDatabase. I think that that is
your problem now.
procedure TCustomSQLQuery.SetDatabase(Value : TDatabase);
var db : tsqlconnection;
begin
if (Database Value) then
begin
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'TCustomSQLQuery.database is being set to ',
Value.DatabaseName, '.');
{$ENDIF}
if assigned(value) and not (Value is TSQLConnection) then
DatabaseErrorFmt(SErrNotASQLConnection,[value.Name],self);
Add ' inherited setdatabase(value);'
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;
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'Calling TCustomSQLQuery.OnChangeSQL because ',
'TCustomSQLQuery.database has been set to ',
Value.DatabaseName, '.');
{$ENDIF}
OnChangeSQL(Self);
end;
end;
end;
Joost
YES! It works!
I was tempted to write down the details of my adventures and why it took
so long to get to this point, but I guess that will just bore everyone.
Suffice to say that most were about learning to use the SVN environment,
and not much to do with the above problem. I think I may have achieved
a functioning SVN environment now.
So now I have the parameter query opening when the form opens, and also
have a master/client link between two sqlqueries, without requiring
code. (Previously I always seemed to need an 'AfterScroll' handler to
get it to work).
I will see what further trouble I can get into.
Thanks,
John Sunderland
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sqldb query parameter properties not loaded?
Op donderdag 24-01-2008 om 20:56 uur [tijdzone +1100], schreef John:
Joost van der Sluis wrote:
Op donderdag 24-01-2008 om 00:09 uur [tijdzone +1100], schreef John:
Snip
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?
You won't often catch me saying Yes I am *sure* I compiled everything
correctly ! I think I did, though.
Quick test is to add a new writeln, see if it is triggered. If so you
have rebuild it properly.
This is my version of set database:
It doesn't contain a call to Inherited.SetDatabase. I think that that is
your problem now.
procedure TCustomSQLQuery.SetDatabase(Value : TDatabase);
var db : tsqlconnection;
begin
if (Database Value) then
begin
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'TCustomSQLQuery.database is being set to ',
Value.DatabaseName, '.');
{$ENDIF}
if assigned(value) and not (Value is TSQLConnection) then
DatabaseErrorFmt(SErrNotASQLConnection,[value.Name],self);
Add ' inherited setdatabase(value);'
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;
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'Calling TCustomSQLQuery.OnChangeSQL because ',
'TCustomSQLQuery.database has been set to ',
Value.DatabaseName, '.');
{$ENDIF}
OnChangeSQL(Self);
end;
end;
end;
Joost
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sqldb query parameter properties not loaded?
Joost van der Sluis wrote:
Op donderdag 24-01-2008 om 00:09 uur [tijdzone +1100], schreef John:
Snip
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?
You won't often catch me saying Yes I am *sure* I compiled everything
correctly ! I think I did, though.
This is my version of set database:
procedure TCustomSQLQuery.SetDatabase(Value : TDatabase);
var db : tsqlconnection;
begin
if (Database Value) then
begin
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'TCustomSQLQuery.database is being set to ',
Value.DatabaseName, '.');
{$ENDIF}
if assigned(value) and not (Value is TSQLConnection) then
DatabaseErrorFmt(SErrNotASQLConnection,[value.Name],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;
{$IFDEF DBDEBUG}
if dbdbgOn then
Writeln(dbdbg, 'Calling TCustomSQLQuery.OnChangeSQL because ',
'TCustomSQLQuery.database has been set to ',
Value.DatabaseName, '.');
{$ENDIF}
OnChangeSQL(Self);
end;
end;
end;
The bits in the {$IFDEF DBDEBUG} are what I have been using to trace the
execution. (Just tracing is not helpful, as I can't read the
properties, so I can't tell where I am). According to this, SetDatabase
gets called once only, from inside DoFixupReferences. At this point the
component state indeed includes csLoading, so db never gets assigned.
(I have also checked this with breakpoints). This makes sense according
to my (limited) understanding of the loader, which is that if a property
that is being loaded is a class, it is always pushed into the fixups
list, not set at the time.
Caveats:
I am rather behind in my svn version, 9468, compared to the one you
generated the diff for. Once I started adding the debug lines, I was
reticent to update and have them all wiped out. Also, I have had to add
the diff in manually, as I am not sure about applying a diff to my
working copy.
I will take just the 'if not (csLoading in ComponentState) then begin'
(and 'end') out and see if I get the original behaviour again.
cheers,
John Sunderland
_
To unsubscribe: mail [EMAIL PROTECTED] with
unsubscribe as the Subject
archives at http://www.lazarus.freepascal.org/mailarchives
Re: [lazarus] sqldb query parameter properties not loaded?
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;
Re: [lazarus] sqldb query parameter properties not loaded?
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
Re: [lazarus] sqldb query parameter properties not loaded?
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
Re: [lazarus] sqldb query parameter properties not loaded?
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
[lazarus] sqldb query parameter properties not loaded?
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 ? thanks, John Sunderland _ To unsubscribe: mail [EMAIL PROTECTED] with unsubscribe as the Subject archives at http://www.lazarus.freepascal.org/mailarchives
