Database programming strategy

What is the best practice to create delphi database application, in terms of where to put the DB component ? Maybe its quite difficult to understand my question :)

Here is the situation :

I would like to use TinyDB component ( It is a nice very small database package. It consists of 2 components, TinyDatabase and TinyTable.

Usually, I have a main form, called "MainForm". I put all the components there.

But, if I created other forms, for example "AddDataForm", I will loose the component reference there.

What is the best way for this ? So I can still refer the components from all forms in my application.

I guess, creating a somekind of global unit, and "create" the component during initialization will do the trick. But is there any way so I can still be able to access the component "visually" in the Delphi IDE ?

I hope you understand my question :)

Who is Participating?
Wim ten BrinkConnect With a Mentor Self-employed developerCommented:
It is like a normal form, except it won't be visible and you can't drop visible controls like panels or labels on it. Only non-visual components. Which makes it perfect for storing global non-visible components.

If you want to share visible components between multiple forms then you have to consider using frames instead. But that's not what you asked for. Both frames and datamodules are important things to learn though. Especially the datamodule is pretty important. Simply because it's the global unit you were thinking about but it allows you to set up the non-visual components in design-time.
Wim ten BrinkSelf-employed developerCommented:
It all depends on the size of your project, the database you're using and the target systems that will run your final application.
In general, don't use a form to store non-visible components but use a Datamodule instead. Then the visual components and non-visual components are nicely separated. Add the datamodule to the uses-clause of every form in your project that needs to access them. This way, the datamodule becomes a shared repository for everything.

The datamodule would be your global unit in this case.

Unfortunately, if you're using the Personal Edition of Delphi you might not have any data modules. In that case, either upgrade to a better Delphi version or drop those components on a form that you're not going to show. (Visible set to false, but still create it!) This non-visible form would then act like a datamodule would.
dudupAuthor Commented:
Thanks for the explanation. I think I have DataModule in my Delphi. But honestly, I dont know how to use it. It is like a normal form.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

you could also, of course, add the main form's unit to your secondary form's uses clause ;-)
Comment only


Both ideas are good (and work).

If you only have one database and a few tables - just stick em on the main form.......


Wim ten BrinkSelf-employed developerCommented:
True... :-)
Personally, I really hate it when two forms are linked to each other, though. I prefer to have them all linked to a single datamodule. This just makes things a lot easier to oversee. I've seen projects with 50+ forms where every form was linked to at least a dozen other forms. When I was asked to solve some bug and add some new features in that code I just showed my boss the finger and told him that rewriting the whole thing was a lot less expensive. I didn't create the garbage and I considered the code unmaintainable.
And I was right. About two months later the new version was ready, with the new features, a new and improved layout, better stability and lots of new bugs that the users didn't know about yet. ;-) But because I'd set it up to have a lot less dependencies between the forms, it also became a lot easier to maintain, and this showed itself after the bug reports arrived. Before, every bug would take about two days to solve. Now, quite a few bugs were solved in a matter of hours and I was left with a lot of time just doing nothing. (Well, nothing... Browsing EE...)

It's better to have all your forms linked to a single datamodule than to have them all cross-linked to each other. It's easier to maintain.

Hi Workshop Alex,

I agree with what you are saying in many ways.

When I said <<If you only have one database and a few tables - just stick em on the main form.......>>

I was quite clearly referring to smaller applications.

Many small database applications revolve around the main form, so referring to it is no big deal - if the app is centered around it.

In the case of an App using TinyDB I would not expect to have 50+forms.

In bigger apps I agree that Data modules are the way to go - for the more experienced programmer.

I use data modules myself and also create in all my applications some other standard modules that I always use.

I have a usefulFunctions module (which does exactly what it says on the tin), a declares module (where I rather obviously put all object declarations, global flags etc), and add others e.g. a Registration module - where I check the Registration status of the software.

I use these and others in all my projects.

Its horses for courses.

I was suggesting to dudup that he has options, depending on the size and scope of his project.


Wim ten BrinkSelf-employed developerCommented:
Well, even with small projects I tend to stay away from having forms refer to the main form. It makes it harder to re-use forms inside other projects. In the past I noticed some problems with projects made by collegues because they had too much dependencies on the main form. Parts of these projects were to be used in another project but we could not do this because of the dependancy to the main form and the enormous overkill the mainform added. Even in small applications the use of a datamodule is very sensible. In general, if a project will have 3 or more forms that are linked to the database, then I'll add a datamodule for the database stuff.

Oh, and I easily expect an application to have 20+ forms, even if it's created with TinyDB. In general, an application might have a grid form to display an overview of a table, and a second edit-dialog to edit one record from what the grid is displaying. So if, e.g. you create a simple application that is keeping scores of your favorite soccer club, you would have one grid and dialog for the clubs, one grid and dialog for the players, one grid and dialog to enter game data and scores, one grid with dialog that links players to clubs and handles transfers of players. These are already 8 forms. If you also use forms to create reports in (like with QuickReports) then you would get even more forms. And then you might also need forms to modify generic configuration data. It might grow to a database with over 15 tables, with three forms per table. That is already 45 forms, without the main form...

Thus, any small application could grow to become huge...

Also, consider frames too. A frame is also some kind of form but it's included as part of some other forms.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.