Skip to main content
HPO Software

4th Dimension Learning Basics

This is the first installment in a hands-on series for developers, citizen developers, and small-team IT builders who want to ship custom business applications on the 4D platform without a full engineering department. The goal of this part is modest but foundational: get a database created, understand the environment you are working in, and lay the groundwork for tables, fields, forms, and value lists that come next.

If you are coming from FileMaker Pro (FMP), much of the vocabulary will feel familiar, and this guide deliberately keeps some of that shared terminology. Where 4D diverges — and it diverges in important ways — those differences are called out explicitly.

Key Takeaways

  • 4D separates your work into Design and User environments (called “modes” throughout this series). Most confusion for newcomers comes from drifting between them unintentionally.
  • The menu bar changes depending on context, even while you stay in Design mode. This is a genuine 4D characteristic, not a bug, and it is the single biggest source of early frustration.
  • A new database is created as a folder containing a Structure file and a Data file. Keeping them together (the default) is the right choice for most small-team projects.
  • The Structure is your schema — tables, fields, relations, forms, and methods. The Data file holds the records. Understanding this split early pays off later.
  • Custom Menus are a powerful 4D feature you will meet properly in the next part of the series. For now, just note that they exist.

Understanding the 4D Environment Model

Before you create anything, it helps to understand how 4D organizes your work. 4D runs in distinct environments — what this series calls “modes” for brevity and for readers arriving from FileMaker. The two you will live in are:

  • Design mode — where you build the structure: tables, fields, relations, forms, value lists, and methods.
  • User mode — where the application actually runs and you (or your users) enter and browse data.

There is also a Custom Menus selection that appears in the Use menu once you are in User mode. Custom Menus let you define your own menu bars, menus, and menu items — effectively shaping the end-user experience of your application. It is a genuinely powerful capability, and the next part of this Learning Series covers it in detail. For now, simply register that it exists so it does not surprise you later.

The mode-switching trap

Here is the caveat that trips up nearly everyone: in 4D, while you are doing one thing, other things can change unexpectedly. In the middle of designing a form or editing a field, you may suddenly find you are no longer in Design mode. The application has shifted you into User mode.

When that happens, the fix is simple but you have to know to look for it:

  1. Check the Use menu.
  2. Confirm that Design is the selected option.
  3. If it is not, select Design to return to your building environment.

If things look strange — menus you do not recognize, a form that suddenly behaves like a running application — this is almost always the cause. Make checking the Use menu a reflex.

Why the menus keep changing

A second, related characteristic is that 4D swaps menu bars depending on what you are doing. Even if you never leave Design mode, the menu bar and its menus will change based on the current context — whether you are editing the structure, working in a form editor, or manipulating a list.

This is intentional. 4D surfaces the commands relevant to your current task rather than presenting one enormous static menu. The trade-off is a steeper learning curve: commands appear to “move” or “disappear” because they are context-sensitive. The documentation in this series tries to keep this straight for you, but be prepared to practice. The frustration does subside once the pattern clicks — and the pattern is consistent once you internalize it.

Creating a New Database

With the environment model in mind, creating a database is straightforward. The following procedure walks through a new sample database.

Step 1 — The Open Database window

When 4D opens, it presents the Open Database window. From here you can either select an existing database or create a new one.

  • To open something you already have, select it from the list.
  • To start fresh, choose “Create a Blank Database.”

Leave the “Create a Database Folder” option checked. This ensures the Structure and Data files are placed together inside a single folder, which keeps your project self-contained and portable. For small-team work, this is almost always what you want — it makes the database easy to back up, move between machines, or hand to a colleague.

Step 2 — The Create a 4D database window

After clicking OK, 4D shows the “Create a 4D database” window. Here you specify two things:

  • Where the database folder will be stored.
  • What the database will be named.

Choose a location you can find again easily, and pick a name that reflects the application’s purpose rather than a temporary label. You will be typing this name into paths and references repeatedly, so clarity now saves confusion later.

When you are satisfied, click Save.

Step 3 — The Structure window

4D then opens the “Structure for Sample Database” window — or, if you named your database something else, “Structure for (whatever you named your database).” This is your Design-mode home base. Everything you build — tables, fields, relations, forms — begins from the Structure.

Structure vs. Data: The Distinction That Matters

One of the most valuable mental models in 4D is the separation between the Structure and the Data.

ComponentWhat it holdsWhen it changesTypical file
StructureTables, fields, relations, forms, value lists, methods, menusDuring design and developmentStructure file
DataThe actual records your users createDuring day-to-day useData file

Why does this matter practically?

  • Backups and deployment. You can back up or move the Data file independently of the Structure in many workflows, and you can update the Structure without disturbing records — provided you manage changes carefully.
  • Development vs. production. You can develop against a copy of the Structure while real users work with the live Data, then merge changes deliberately.
  • Troubleshooting. When something behaves oddly, knowing whether the problem lives in the schema (Structure) or in a specific record (Data) narrows the search enormously.

Keeping both files inside one database folder — the default from Step 1 — is the simplest arrangement and the right starting point for most small teams. As your application grows, you can revisit how you separate them.

A Practical Checklist Before You Build

Once your Structure window is open, resist the urge to immediately start clicking. A few minutes of planning prevents hours of rework. Use this as a pre-build checklist:

  • Name the application’s purpose in one sentence. If you cannot, the scope is not yet clear enough to model.
  • List the real-world things you track (customers, orders, invoices, inventory items). Each becomes a candidate table.
  • For each thing, list its attributes. These become fields.
  • Identify how the things relate (a customer has many orders; an order has many line items). These become relations.
  • Sketch the screens users will actually need. These become forms.
  • Note any dropdowns or pick-lists users will expect. These become value lists.

This checklist maps directly onto the series structure: tables, data fields, forms, and value lists are the next four topics, followed by entering sample data. Doing the thinking up front means each subsequent step has a clear target.

Common Pitfalls for Newcomers

A short list of the traps that catch people early, drawn from the characteristics described above:

  • Assuming you are still in Design mode. You may not be. Check the Use menu.
  • Panicking when the menu bar changes. It is context-sensitive by design. The commands you need are usually still there, just relocated.
  • Naming the database carelessly. You will reference this name constantly. Choose well.
  • Unchecking “Create a Database Folder” without a reason. Keeping Structure and Data together is the sane default for small teams.
  • Trying to learn Custom Menus before the basics. It is powerful, but it is a later topic. Tuck it away for now.

Where This Series Goes Next

This part established the foundation: the environment model, the mode-switching behavior, and the creation of a new database with its Structure and Data files. From here, the series proceeds in a deliberate order:

  1. Database Properties — configuring the settings that govern your database’s behavior.
  2. Tables — defining the entities your application tracks.
  3. Data fields — specifying the attributes of each table.
  4. Forms — building the screens users interact with.
  5. Value Lists (choice lists) — providing controlled input options.
  6. Entering sample data — populating the database to test your design.

Each step builds on the last, so working through them in order — rather than jumping ahead — will keep the mode-switching and menu-bar quirks from compounding. If you are coming from FileMaker, you will find the concepts transfer well; the main adjustment is 4D’s environment model and its context-sensitive interface.

For readers who want to ground the terminology in the broader landscape, the concept of a database schema — the formal description of tables, fields, and their relationships — is well documented by Wikipedia’s database schema overview. The relational model that underpins much of this thinking traces back to [E.

F. Codd’s relational model](https://en.wikipedia.org/wiki/Relational_model), and the general practice of separating structure from data is a cornerstone of database design. For the platform itself, 4D maintains official documentation and community resources under the 4D name.

Frequently Asked Questions

Why does 4D keep switching me out of Design mode?

4D can change environments unexpectedly while you are working, which is a known characteristic of the platform rather than a malfunction. When it happens, open the Use menu and confirm that Design is selected. If it is not, select it to return to your building environment. Making this check a habit resolves the majority of “why is this behaving strangely?” moments.

Why do the menu bars and menus change while I stay in Design mode?

4D uses context-sensitive menu bars, so the available menus and commands change depending on what you are currently doing — editing the structure, working in a form, or manipulating a list. This is intentional design that surfaces relevant commands rather than one giant static menu. The trade-off is a learning curve, but the pattern becomes predictable with practice.

What is the difference between the Structure and the Data?

The Structure is your schema: tables, fields, relations, forms, value lists, and methods. The Data file holds the actual records your users create and edit. Keeping them in one database folder — the default when you check “Create a Database Folder” — is the simplest arrangement for most small-team projects and makes the database easy to back up and move.

Should I leave “Create a Database Folder” checked?

Yes, for most projects. Leaving it checked places the Structure and Data files together inside a single folder, keeping your database self-contained and portable. There are advanced scenarios where you might separate them, but those come later. As a newcomer, the default is the right choice.

What are Custom Menus, and should I learn them now?

Custom Menus let you create your own menu bars, menus, and menu items, shaping the end-user experience of your application. They are a powerful 4D feature, but they are not the place to start. The next part of this Learning Series covers them in detail. For now, simply note that the Custom Menus option appears in the Use menu once you are in User mode.

I am coming from FileMaker Pro. What should I watch out for?

Much of the vocabulary transfers, which is why this series keeps familiar terms like “mode” rather than 4D’s own “environment.” The main adjustments are 4D’s environment model — the ease of drifting between Design and User modes — and its context-sensitive menu bars. Expect some initial frustration with menus that seem to move, and plan to practice before it feels natural.


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

Browse our latest guides and reviews.

Read more →