[SOLVED] Question about Data Module

[1HuntnMan]

I'm relatively new to Lazarus.  On this app I started my first project, I started creating the main form and adding other forms which use a table(s), etc.  Got to reading about a Data Module so created one File-New-Data Module.  So, it appears to me that it's really just a form/unit. But, I am moving all the Data Tables and Data Sources over to it and every form that needs access to a table(s), just USING that form. It's working and I like that I have all the Data Table/Sources on just one form-Data Module.

Is that it or does a Data Module form have different code, etc. than just another form/unit added to your app. that's var name is DMPMS vs. FrmClientsMgt?

Also, on the Data Module I put all my table components on it, do I keep all the datasets there also or do I just put the DataSet component on the form that uses a table and point the dataset to the DMPMS.DbfPMS?

[Thaddy]

TDataModule is about separation of responsabilities.
They work as a container for data elements that can be distinctly handled as a group. That can be databases, tables, queries etc. And also the datasets.
If your database application becomes more complex they will be become more important, but in principle they are not needed for simple solutions. They are simply a container, just like a Tframe.

[1HuntnMan]

Okay, finished moving all table and datasets to the data module.  Compiles with no errors. But, when I attempt to run application without Laz active I get an access violation.

When I removed the TDbf components and the TDataSource components from all the forms except the DM, should I have left the DataSource components on the forms where the tables are referenced? So, for example if I have a DBGrid on a form, in it's DataSource property, I entered DataModulePMS.DSCategories. Would the correct way would have the DataSource on the form with the DBGrid and it's DataSource property pointing to the DataSource on the Categories form instead of the Data Module.  Would this be the issue?

[Hansvb]

Take a look at the project source. Data module should usually be at the front of the uses list.

[Thaddy]

No. In this particular case that does not matter.

[1HuntnMan]

I moved the DMESPMgt (unit name) to the beginning of the Uses clause and that cured the Access Violations!
Tks Hansvb

[1HuntnMan]

Also, searching thru other posts, I found and learned how important the order of the units in the Uses clause.

[1HuntnMan]

I thought moving the Data Module to the beginning of the Uses clause in every form would eliminate having the tables Dbf's and DataSources on each form that allows editing of tables, i.e. States, Countries, Categories, etc.

This is what I did so remove the clutter of every form having the Dbf/DS components on every form.  I removed them and moved them all to a Data Module. Corrected all the code on forms by adding the Data Module unit at the beginning (Thaddy's advice) USES on every form. The way this app is designed is the opening form is the Clients/Customers.  All tables are used on this form, Clients, Contacts, Categories, States, Countries, ReferredBy, etc. After moving to DataModule, the main form, Clients Mgt., no Access Violation errors (Abort or Continue risking data corruption). But, if the user decides to rebuild the tables under File-Maintenance, I can run data tables packing, regenerating indexes, etc. But, when I close, Access Violation and abort. If the user attempts to maintain the Client Categories, same problem when you close the Categories Maint. form, Access Violation and Abort, same with States, Countries, Referrals, etc. I have the Data Module at the beginning of every form's Uses clause. Also, when loading each form from the main, I'm ShowModal.

Code: Pascal  [Select][+][-]

1. procedure TFrmPMSMain.MnuFileMaintClick(Sender: TObject);
2. begin
3.   try
4.     if PMSDM.DbfClients.Modified then
5.       PMSDM.Dbf.ClientsPost;
6.     PMSDM.DbfStates.Close;
7.     PMSDM.DbfCntries.Close;
8.     PMSDM.DbfCategories.Close;
9.     PMSDM.DbfClients.Close;
10.     Application.CreateForm(TFrmRebldPMSDB, FrmRebldPMSDB);
11.     FrmRebldPMSDB.ShowModal;
12.   finally
13.     PMSDM.DbfClients.Open;
14.     PMSDM.DbfStates.Open;
15.     PMSDM.DbfCntries.Open;
16.     PMSDM.DbfCategories.Open;
17.     FrmPMSMain.Refresh;
18.   end;
19. end;
20.  

Another bit of info. In the App's.lpr I also put the DM unit at the beginning of it's Uses clause because that's where the DataModule form is created just before the main form is created.

Code: Pascal  [Select][+][-]

1. uses
2.   {$IFDEF UNIX}
3.   cthreads,
4.   {$ENDIF}
5.   {$IFDEF HASAMIGA}
6.   athreads,
7.   {$ENDIF}
8.   Interfaces, // this includes the LCL widgetset
9.   Forms, datetimectrls, printer4lazarus, lhelpcontrolpkg,
10.   { Main Unit added below ... }
11.   DmPMS, ClientsMain;
12.  
13. {$R *.res}
14.  
15. begin
16.   RequireDerivedFormResource:=True;
17.   Application.Title:='PMS';
18.   Application.Scaled:=True;
19.   Application.Initialize;
20.   Application.CreateForm(TPMSDM, PMSDm);
21.   Application.CreateForm(TFrmClientsMain, FrmClientsMain);
22.   Application.Run;
23.  

[Joanna from IRC]

I had a problem with things trying to use data module before it was ready I believe I solved it by putting code into the unit initialization section to create the data module if it was nil. I was unable to control what order the units were initialized in.

[1HuntnMan]

Joanna,
   I think at this point in my development of 2 systems that I'm going back to NO Data Module. On the other app I'm almost finished with, just testing by users I tried using a Data Module, 4 months ago and gave up. This new one I tried it again just for testing and maybe I would learn something new.  If you read earlier in this thread, THaddy advised, "Data module should usually be at the front of the uses list."  I did that and I could at least get into the Main Form without an access violation but, any forms launched from the Main Form has the same issue with constant "Access Violations".
   I'm going to leave it at this and go back to my other app and wait a day.  If no real replies for solutions, then I'll come back to this current app and just remove the Data Module and move on with life.
Tks and take care, 1HuntnMan aka Donald

[TRon]

Code: Pascal  [Select][+][-]

1. procedure TFrmPMSMain.MnuFileMaintClick(Sender: TObject);
2. begin
3.   try
4.     if PMSDM.DbfClients.Modified then
5.       PMSDM.Dbf.ClientsPost;
6.     PMSDM.DbfStates.Close;
7.     PMSDM.DbfCntries.Close;
8.     PMSDM.DbfCategories.Close;
9.     PMSDM.DbfClients.Close;
10.     Application.CreateForm(TFrmRebldPMSDB, FrmRebldPMSDB);
11.     FrmRebldPMSDB.ShowModal;
12.   finally
13.     PMSDM.DbfClients.Open;
14.     PMSDM.DbfStates.Open;
15.     PMSDM.DbfCntries.Open;
16.     PMSDM.DbfCategories.Open;
17.     FrmPMSMain.Refresh;
18.   end;
19. end;
20.  

Just some verification question... if you create FrmRebldPMSDB for use with showmodal each time you select the menu item... then where exactly is it destroyed ?

[Hansvb]

As far as I know, the data module has to be created first and then the form(s). You can do that in the project source. That's somerhing different then putting the data module in each unit at the front. If that doesn't solve the access violation, then with me it's usually the case that I want to use a data source that has already been shut down.

See the last post in: https://forum.lazarus.freepascal.org/index.php?topic=41408.0

[dseligo]

As far as I know, the data module has to be created first and then the form(s).

It has to be created before you use it.
You can also change creation order in menu Project/Project Options/Forms in the 'Auto-create forms' list. See attachment: DM is name of my data module (I have other data modules in this project, but I create them manually).

[TRon]

It has to be created before you use it.

+1

It also means that when you depend on the datamodule to be created first that you seem to do all kind of initializations before a (single) form is even been shown (which is usually a bad idea).

[egsuh]

The orders of units appearing in "uses" clause do not matter IN GENERAL. They may matter when dependencies exist among the units in the uses clause.

Based on your explanations, it seems that trying to access datamodules/forms which have not been created causes access violations. You may auto-create datamodules/forms or create within the codes.

So the creation order seems to matter more in this case.