4th Dimension Learning Basics

From the archive of hposoft.com

Key Takeaways

The 4D Toolbar is a convenience layer, not a requirement — hiding it is a legitimate first step for many developers because the icons are non-obvious and the menu bar exposes the same commands.
Database Properties are best left at their defaults while you are learning; changing them prematurely can mask the behavior you are trying to understand.
Properties are stored with the database structure, so they travel with the project and affect every developer and every deployed client — treat them as team-level decisions, not personal preferences.
The distinction between database properties and application/preference settings matters: one changes the product you ship, the other changes only your working environment.
A disciplined setup order — create database, review properties, define tables, define fields, build forms, wire value lists, enter sample data — prevents rework later.

The 4D Toolbar sits at the top of the Design environment and offers quick access to common actions: opening the Structure editor, the Form editor, the Method editor, running the database, and so on. In principle that sounds helpful.

In practice, many developers — including the author of the original notes this article is based on — find it actively distracting. The icons are not self-explanatory, and hovering to discover what each one does interrupts the mental flow of designing a table or a form.

If that describes you, you can turn it off. Open the Database Properties dialog from the Design menu (in classic 4D this is reached through the Properties/Preferences area), locate the Show Toolbar checkbox, and uncheck it. The toolbar disappears from the Design environment, and you navigate instead through the menu bar — Structure, Form, Method, Run, and so on.

This is a small decision, but it illustrates a larger principle worth internalizing early: 4D gives you a lot of surface area, and not all of it is useful to you on day one. Your job as a beginner is to reduce noise so you can see the underlying model — tables, fields, forms, and the relationships between them.

A few practical notes on the toolbar decision:

Hiding it is reversible. Nothing about unchecking the box is destructive. If you later want it back, re-open the same dialog and re-check it.
The menu bar is the source of truth. Every toolbar button corresponds to a menu command. Learning the menu path is more durable knowledge than learning an icon’s position.
Keyboard shortcuts beat both. Once you know the menu commands, learning their shortcuts (for example, the shortcut to run the database or to open the Structure editor) is faster than either the toolbar or the menus.
Your preference may differ from your teammate’s. Because this setting lives in database properties, it is shared. If you work on a team, agree on a convention rather than flipping it back and forth.

Database Properties: What They Are and Why They Matter

The Database Properties dialog is where you configure settings that apply to the database as a whole rather than to a single table, field, or form. It is one of the first dialogs you will meet after creating a new database, and it is easy to either ignore it entirely or to over-configure it.

The key thing to understand is the scope of these settings. Database properties are stored inside the database structure file. That means:

They are shared — every developer who opens the structure sees the same property values.
They are shipped — when you build a compiled application or deploy the interpreted database, the properties go with it.
They are persistent — they survive restarts, rebuilds, and (in most cases) structure upgrades.

Contrast that with settings that live in the 4D application itself or in a per-user preferences file. Those affect only your machine and your session. The distinction matters because a change that feels like “just my preference” can actually alter behavior for everyone.

A practical rule for beginners

The original guidance here is sound and worth repeating with emphasis: leave the other properties at their default values for now. There are many options in that dialog, and most of them address scenarios you have not encountered yet. Changing a property you do not understand is a reliable way to create a bug that looks like a code problem but is actually a configuration problem — the hardest kind to diagnose.

As you become more familiar with 4D, you will start to recognize when a property is relevant. That is the right time to change it. Experimentation is encouraged, but do it deliberately: change one property, observe the effect, and note what happened.

How to decide whether to change a property

When you are tempted to modify something in the Database Properties dialog, run it through these questions:

Do I understand what this setting controls? If not, leave it. Look it up first.
Is this a project-wide decision or a personal one? If it is personal, it probably does not belong here.
Will this affect deployed clients? If yes, it needs to be a conscious, documented choice.
Can I undo it easily? Most properties are reversible, but some interact with others in ways that are not obvious.
Have I tested it in a copy of the database? For anything non-trivial, test on a duplicate structure before committing.

The Setup Sequence, and Where Properties Fit

It helps to see the properties step in context. The learning path laid out in this series runs:

Create a database — start a new structure file.
Database Properties — review the project-wide settings and, for now, accept the defaults.
Tables — define the entities your application will store (customers, invoices, products, and so on).
Data fields — define the attributes of each table, choosing appropriate field types.
Forms — design the input and display screens users will actually work with.
Value lists (choice lists) — supply controlled vocabularies so users pick from valid options instead of typing free text.
Enter sample data — populate the database so you can test forms and lists against realistic content.

Properties come second because they frame everything that follows, but they are deliberately not the place to spend your early energy. The intellectual work of 4D is in steps 3 through 6: getting the data model right, then making it usable.

Why the order matters

Tables before fields. You cannot sensibly define a field until you know which table it belongs to and what that table represents.
Fields before forms. A form is a view onto fields. Designing forms first leads to fields that exist only to serve a layout.
Forms before value lists (in practice). You often discover which fields need a choice list while building the form that uses them.
Sample data last, but not least. Empty forms hide problems. A form that looks fine with zero records can fall apart with real names, long addresses, and edge-case values.

Database Properties vs. Application Preferences: A Comparison

Beginners frequently conflate these two categories. They are configured in different places, have different scopes, and should be treated differently.

Aspect	Database Properties	Application / User Preferences
Scope	The database structure and everything built from it	Your 4D application and your working session
Who it affects	All developers and all deployed clients	Typically just you
Where it lives	Inside the structure file	In the 4D application or a per-user settings location
Travels with the project?	Yes	No
Typical examples	Toolbar visibility, startup behavior, structure-wide options	Window positions, editor font, recent-file lists
Beginner advice	Accept defaults; change deliberately and document	Adjust freely to suit your comfort

The toolbar setting is a slightly unusual case: it feels like a personal preference, but it is exposed as a database property. That is exactly why it is worth pausing on. When a setting’s location and its apparent scope disagree, slow down and think about who else is affected.

Practical Guidance for Your First Session

If you are sitting down with 4D for the first time, here is a concrete way to spend the first hour productively.

Create the database with a clear, descriptive name. Avoid spaces and special characters in the structure file name if you plan to move it between machines or reference it from scripts.
Open Database Properties and read through the options without changing them. Reading is free; it builds a mental map of what is configurable.
Uncheck “Show Toolbar” if you find it distracting. This is the one change the original guidance endorses, and it is safe.
Close the dialog and move on to Tables. Resist the urge to tour every tab.
Keep a short notes file recording any property you do change and why. Future-you, and your teammates, will thank you.

Common beginner mistakes at this stage

Over-configuring before modeling. Spending an hour in the properties dialog and ten minutes on the data model is backwards.
Assuming a setting is personal when it is shared. See the comparison table above.
Changing several properties at once. If something breaks, you will not know which change caused it.
Ignoring the dialog entirely. Defaults are usually right, but “usually” is not “always” — know what is there.

Where to Go Deeper

The 4D platform has a long history and a substantial body of documentation. The official 4D documentation site maintained by 4D SAS is the authoritative reference for every property, command, and editor in the product, and it is worth bookmarking early. For general background on the product and its lineage, the Wikipedia article on 4D (programming language) provides useful context on how the platform evolved from a relational database into a full application development environment.

If you come from a SQL background, the Wikipedia overview of the relational model is a useful refresher on the concepts that 4D implements in its own idiom — tables, records, fields, and relations — even though 4D’s terminology and tooling differ from a typical SQL server. And because 4D applications are frequently deployed alongside general-purpose business software, the Microsoft Learn and Apple Developer documentation sites are handy references when you need to understand the host operating system’s conventions for windows, files, and user interface behavior.

None of that replaces hands-on time in the Structure editor. The fastest way to learn 4D is to build a small, real database — something you actually want to track — and let the properties dialog stay quiet in the background until you have a reason to open it.

Frequently Asked Questions

It is entirely a matter of personal working style. Many developers hide it because the icons are not intuitive and the menu bar exposes the same commands, while others prefer the one-click access. The setting is reversible, so try it both ways and keep whichever helps you stay focused.

Are database properties the same as my personal preferences?

No. Database properties are stored with the structure file and therefore apply to every developer and every deployed client. Personal preferences affect only your own machine and session. When a setting feels personal but lives in the database properties dialog, treat it as a shared decision.

Why should I leave the default property values alone at first?

Because most of the options address situations you have not encountered yet, and changing a setting you do not understand can produce behavior that looks like a code bug but is really a configuration issue. Defaults are a reasonable starting point; revisit them once you know what each one does.

What is the right order for setting up a new 4D database?

Create the database, review the properties, define your tables, define the fields within each table, design the forms, set up value lists for controlled fields, and then enter sample data. This order keeps each decision grounded in the one before it and avoids rework.

Do I need to configure properties before building tables and forms?

No. The properties dialog frames the project, but the substantive work happens in the Structure and Form editors. You can build a complete, working database without touching most properties, and you can return to them later when a specific need arises.

How do I know when it is time to change a database property?

When you can state clearly what the setting controls, who it affects, and what you expect to change as a result — and ideally after testing it on a copy of the structure. If you cannot answer those questions yet, leave it at the default and keep building.

More on 4D (4th Dimension) database & low code app development tutorials

Browse our latest guides and reviews.