I have this strange behaviour in lazarus 0.9.26.2 fpc 2.2.2 on winxpsp2: a TZquery (zeos6.6.6) on a form with the Connection property assigned in designtime, raising an exception in the form.create :
procedure TZAbstractRODataset.CheckConnected;
begin
if Connection = nil then
raise EZDatabaseError.Create(SConnectionIsNotAssigned);
Connection.Connect;
end;
Clearing the Connection property in designtime, and assigning it in the form.create procedure, solves the problem.
Then, reassigning in designtime and clearing the assignment in the form.create -> no exception anymore.
I had this a few times, unpredictable. Any idea how come?
Guido
ConnectionIsNotAssigned
Moderators: gto, cipto_kh, EgonHugeist
- mdaems
- Zeos Project Manager
- Posts: 2766
- Joined: 20.09.2005, 15:28
- Location: Brussels, Belgium
- Contact:
Guido,
I'm not sure, but this may have to do with the sequence used to load the objects. I have no idea how fpc/lazarus decides in which order objects are created and when in the startup sequence the zquery and zconnection objects get their settings.
My guess (from something I remember reading before) is you should look in what order the Forms objects and data modules are created.
I imagine I will have ths problem when I change one of my projects this way:
I'm not sure, but this may have to do with the sequence used to load the objects. I have no idea how fpc/lazarus decides in which order objects are created and when in the startup sequence the zquery and zconnection objects get their settings.
My guess (from something I remember reading before) is you should look in what order the Forms objects and data modules are created.
I imagine I will have ths problem when I change one of my projects this way:
Code: Select all
begin
Application.Initialize;
//-- >>> Application.CreateForm(TZeosData, ZeosData);
Application.CreateForm(TFMainForm, FMainForm);
Application.CreateForm(TFVoorraadForm, FVoorraadForm);
Application.CreateForm(TFSQLForm, FSQLForm); //-- >>>
form using a data grid
Application.CreateForm(TFNewDbForm, FNewDbForm);
Application.CreateForm(TFRekeningkiezer, FRekeningkiezer);
Application.CreateForm(TFBestellingkiezer, FBestellingkiezer);
Application.CreateForm(TFOpmerkingDialoog, FOpmerkingDialoog);
Application.CreateForm(TZeosData, ZeosData); //-- >>> datamodule containing queries and connections
Application.Run;
-
- Senior Boarder
- Posts: 93
- Joined: 01.07.2009, 16:07
Hi Mark,
In runtime, I have the TZConnection on the MainForm, connected and well, when I try to create another form with the TZQuery, which uses the Mainform.ZConnection.
For reason of the creation order, I tried shuffling with the objects in the .lfm of the new form, but that didn't help. Do you think it is possible that, when one makes only small changes and many re-compilings (trial and error programming) lazarus and/or delphi sometimes miss these small changes and compile the 'old' version ? Because, once settled, the problem doesn't re-appear at the same point.
Guido
In runtime, I have the TZConnection on the MainForm, connected and well, when I try to create another form with the TZQuery, which uses the Mainform.ZConnection.
For reason of the creation order, I tried shuffling with the objects in the .lfm of the new form, but that didn't help. Do you think it is possible that, when one makes only small changes and many re-compilings (trial and error programming) lazarus and/or delphi sometimes miss these small changes and compile the 'old' version ? Because, once settled, the problem doesn't re-appear at the same point.
Guido
-
- Senior Boarder
- Posts: 93
- Joined: 01.07.2009, 16:07
Hi Mark,
this is from my lpr file:
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms
{ you can add units after this }, MainformUnit, LResources, zcomponent,
persoonsgegevenswijzigenunit, OgmBoekingenUnit, bankboekingenUnit1,
nieuwepersoonunit, TransformUnit, ImagesForLazarus, AanmeldingUnit,
inschrijvingenUnit, persoonselectieunit, RapportUnit, lazreport,
ledenlijstrapportunit;
{$IFDEF WINDOWS}{$R project1.rc}{$ENDIF}
begin
{$I project1.lrs}
Application.Initialize;
Application.CreateForm(Tmainform, mainform);
Application.Run;
end.
So, the forms are created in runtime in from the menu of the mainform.
( with Tinschrijvingenform.create(self) do showmodal;)
I have one TZconnection component on the mainform, that is used by all the queries on the forms. The connection property is assigned in designtime. I keep getting this error; then I have to unassign in IDE and assign programmatically in the oncreate of the form.
Sometimes there is no error, then after changing some things, for example creating some columns in a grid, and recompiling, the error comes up.
I admit, it would be proper programming to build a datamodule. But nevertheless, this is odd behaviour.
Guido
this is from my lpr file:
program project1;
{$mode objfpc}{$H+}
uses
{$IFDEF UNIX}{$IFDEF UseCThreads}
cthreads,
{$ENDIF}{$ENDIF}
Interfaces, // this includes the LCL widgetset
Forms
{ you can add units after this }, MainformUnit, LResources, zcomponent,
persoonsgegevenswijzigenunit, OgmBoekingenUnit, bankboekingenUnit1,
nieuwepersoonunit, TransformUnit, ImagesForLazarus, AanmeldingUnit,
inschrijvingenUnit, persoonselectieunit, RapportUnit, lazreport,
ledenlijstrapportunit;
{$IFDEF WINDOWS}{$R project1.rc}{$ENDIF}
begin
{$I project1.lrs}
Application.Initialize;
Application.CreateForm(Tmainform, mainform);
Application.Run;
end.
So, the forms are created in runtime in from the menu of the mainform.
( with Tinschrijvingenform.create(self) do showmodal;)
I have one TZconnection component on the mainform, that is used by all the queries on the forms. The connection property is assigned in designtime. I keep getting this error; then I have to unassign in IDE and assign programmatically in the oncreate of the form.
Sometimes there is no error, then after changing some things, for example creating some columns in a grid, and recompiling, the error comes up.
I admit, it would be proper programming to build a datamodule. But nevertheless, this is odd behaviour.
Guido