Inactive DataSource property of DBxxxx components from Object Inspector

[Bono]

Hello from Japan. To dear all developer.

I apologize for my poor English.

I discovered inactive DataSource / DataField / ListSource / KeyField / ListField properties of DBxxxx components by set via the Object Inspector.
My use case involves placing db component to common unit (Form unit).

The compiler doesn't seem to recognize references to `[UnitName].[TDataSet]`.

As a temporary workaround, I'm setting the DataSource in code.

thanks.

[jamie]

Only what you place on the TFORM1 using the object inspector will the system see the DataSource connected to the other components.

 Normally these are at the top of TFORM1 inside the class. If you are manually placing these items elsewhere, you need to connect them at run-time.

 If this isn't the problem, then please post a simple short example of a failure via a Project.zip using the publish project in the "Project" menu.

Jamie

[Bono]

Hi, thanks jamie.

Since it's a bit tricky to keep this project simple, I'll just paste the GitHub page URL here.

https://github.com/BonoJovi/KakeiBon.git

As you suggest, placing DB components like TDataSource on the top form might be preferable. However, due to the large number of components, I placed them on a separate form.
Even if placed on the top form, accessing that top form's DB components from subsequent forms would still involve referencing an external form. Therefore, I believe the same issue would persist regardless.

[jamie]

Ok, that is a large project for me to look at.

Have you tried using a Data Module instead of a form?

 With that you can place many objects on there to be used all over the place, and it seems the Object Inspector also allows you to link them.

Jamie

[CharlyTango]

Data modules are designed precisely for this purpose. Data modules can be thought of as TForms without visuals or as carrier elements for invisible components.
Especially in database applications, things can quickly become confusing if you have too many components on a TForm.

My structure:
I have a data module that contains ONLY the database connection (e.g. SQL connection, transaction, monitoring). I have also made this data module a singleton object so that it is always accessible throughout the programme.

I use data-sensitive controls on TForm and if there are only 2 or 3 queries and dataset components, I place them on the form.
If there are more, the TForm gets its own data module. Then everything becomes quite clear.

When the data module or TForm is opened, the connection is assigned to the queries.

I also use data modules to structure other components, e.g. image lists.

[Bono]

Hi, Jamie

Sorry, not yet push the new state project to GitHub.

Now create a small sample project.

But my small sample project is SYSSEGV.

Debugging now, wait a moment please.

[jamie]

Put it here, the simple project.

use the PROJECT: PUBLISH PROJECT.

That will make a small zip file of only the needed items, then you can attach it here.

[Bono]

Hi, CharlyTango.

Thanks post.

You think so me too.

Too much information—like the number of components on a form—not only reduces development efficiency but also becomes a breeding ground for bugs. I think it's best to narrow down the information visible at once as much as possible.

No matter how excellent Lazarus's structuring is, if the human-made parts aren't structured, its effectiveness is halved.
Besides, Lazarus + Free Pascal is still under development, and I don't think it's reached the point where structuring is automated without developers having to worry much about it.
And let's not forget, the IDE and components themselves still have plenty of bugs.I saw it mentioned somewhere recently: Lazarus developers say that since its history is considerably shorter compared to Delphi, it's inevitable that some bugs remain.

[Bono]

Ok, Jamie

 Once I've fixed the bugs in the sample program I'm currently working on, I'll zip it up and attach it here.

[Bono]

Hi, Jamie

Sorry to keep you waiting.

I've finished a small sample project and will upload it now.

Please check the section marked “Check Here Please !!” in UManageUser.pas (inside the FormShow event handler).

[egsuh]

I haven't looked into your example, but

`[UnitName].[TDataSet]` is not correct form.

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

1. unit DataModule;
2.  
3. type
4.      TDataModule1 = class(TDataModule)
5.          dataset: TBufDataset;  
6.          datasource1: TDataSource;
7.          DBGrid1 : TDBGrid;
8.          .....
9.      end;
10.  
11. var
12.     DataModule1: TDataModule;
13.  
14. implementation
15.  
16. end;

And in other units,

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

1. unit Mainform;
2. uses    DataModule;
3.    ...............
4.  
5. begin
6.      DataModule1.DataSet := ....;    // should reference a variable, not type themselves.
7.  
8. end;

[Bono]

Hi, egsuh.

Oh. I misspell...

I see. Depending on the scale of the code, the way you suggested splitting up the objects seems like it could be effective.


Below is an example of my current code.

I'm not sure if this is the best approach, but since the form calls span multiple layers, I wanted to separate the TDBGrid, TDBNavigator, input fields, and DB components to make them more generic.

While there are other ways to separate DB components in object design, I think this approach is fine for now.

Common module.

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

1. unit UCommonDB
2.  
3. type
4.     TFrmCommonDB = class (TForm)
5.         Connection1: TSQLite3Connection;
6.         DataSource1: TDataSource;
7.         Transaction1: TSQLTransaction;
8.         Query1: TSQLQuery;
9.            
10.         Connection2: TSQLite3Connection;
11.         DataSource2: TDataSource;
12.         Transaction2: TSQLTransaction;
13.         Query2: TSQLQuery;
14.            
15.         Connection3: TSQLite3Connection;
16.         DataSource3: TDataSource;
17.         Transaction3: TSQLTransaction;
18.         Query3: TSQLQuery;
19.  
20.                           ・
21.                           ・
22.                           ・
23.     end;
24.  

Other main form.

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

1. unit UMainForm;
2.  
3. ・・・・・
4.  
5. type
6.     TMainForm = class(TForm)
7.         DBGrid1: TDBGrid;
8.          ・・・・
9.     end;
10.  
11. var
12. ・・・・
13.  
14. implementation
15. uses
16.     UCommDB;
17.  
18. constructor TMainForm..Create;
19. begin
20.     CommDB := TFrmCommonDB.Create;
21. end;
22.  
23. procedure TMainForm.FormShow(Sender: TObject);
24. begin
25.     with CommDB do begin
26.         with Query1 do begin
27.             SQL.Text := 'SELECT * FROM TBL_USERS';
28.             Open;
29.         end;
30.         DBGrid1.DataSource := DataSource1;  // ←Here
31.     end;
32. end;
33.  

And other sub form.

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

1. unit SubForm;
2.  
3. ・・・・・
4.  
5. type
6.     TSubForm = class(TForm)
7.         DBGrid2: TDBGrid;
8.          ・・・・
9.     end;
10.  
11. var
12. ・・・・
13.  
14. implementation
15. uses
16.     MainForm;
17.  
18. procedure TSubForm.FormShow(Sender: TObject);
19. begin
20.     with MainForm do begin
21.         with CommDB do begin
22.             with Query2 do begin
23.                 SQL.Text := 'SELECT * FROM TBL_SHOP';
24.                 Open;
25.             end;
26.             DBGrid2.DataSource := DataSource2;  // ←Here
27.         end;
28.     end;
29. end;
30.  

[CharlyTango]

It Seems to me that you didn't understood a concept. You only need ONE set of SQLite-Connection/Transaction for the complete application. There is no need to repeat that for each and every SQLQuery. Just Assign the connection and you ar on the go. The connection is opened once and is open until the application ends.

I attached a sample project which shows that. The main datamodule is dmmain.pas

What could be interesting for you is the form fcustomer. Just one single SQL Statement and it works. Lazarus maybe has some bugs, but as an old delphi (since Delphi2) veteran i can say that it is more stable than you might think.

Maybe there is an advantage to collect all SQL statements in one if there is a possibility to change them often. I prefer to put things together in a form which belong together.

You put your datamodule at the first place of the autocreate-forms list. remove it and create it yourself at a defined position in your starting routine (shown in example code)

Certainly you can put each and every data field in a seperate Label or nidependent edit control. That results in quite a huge typing amount which does not seem to me that it is necessary. The only exception for me ist that you urgently need the possibilities of controlong the process. Otherwise I'd use database enabled controls.

You also can have more control over the process reading writing etc data controlling the used events. but that could be another thread.


In such an application

[Bono]

Hi, CharlyTango

Admittedly, I can't deny my lack of understanding.

While I used Delphi in its early days, circumstances led me away from programming for nearly 30 years. I only recently resumed programming with Lazarus last year.

However, thanks to your excellent sample project, I've gained a better understanding of how to use the DB component. Thank you.

With this knowledge, I think I can improve the database architecture of the household budget app I'm currently developing.

[egsuh]

Does your code cause compiler error or runtime error, or simply show no data?