4th Dimension Learning Basics

Jeff Hopkins is a 4D Partner, Expert FileMaker Pro Developer, Owner of HPO SOFT, and founder of the nonprofit Association of Database Developers, Inc. When not filling some of the above roles he is tirelessly working to help others on various database discussion lists.

Key Takeaways

• In 4D, build in a specific order: Tables → Data Fields → Forms → Calculations/Methods. Skipping ahead creates rework.
• You can build a complete, useful one-table flat-file application without writing a single method — except for one optional calculation (an “Object Method”).
• 4D’s Design mode menu bar changes depending on which window is open. If the Structure menu disappears, close all open windows (not the 4D application itself) and it returns.
• 4D and FileMaker Pro (FMP) share a low-code philosophy, but 4D exposes more structure up front — which is why the creation order matters more.
• Create several small test databases rather than one big one while learning; 4D’s behavior is sometimes surprising, and experimenting is the fastest way to internalize it.
• Once you master the flat-file basics here, related files, methods, calculations, runtimes, compiled versions, and web hosting all become reachable.

i. Introduction

As indicated in Part I, in the following document 4D will mean 4th Dimension and FMP will mean FileMaker Pro. The following document was created on a Macintosh. While there may be slight differences in some of the screen shots when using 4D for Windows, the same procedure should work on either platform.

Many will say that you need to be a programmer to create 4D programs. While it certainly doesn’t hurt, just as with FMP, there is much you can do without ever getting into programming or script writing. This part will take the reader through the development of a simple one Table flat file. With the exception of one simple calculation (called an “Object Method”) there will be no methods or calculations.

The reason I am doing this is because once you have mastered what follows you can go on to the really neat stuff — related files, methods, calculations, runtimes, compiled versions and web hosting.

I have found keeping straight where you are in 4D to be the hardest part in the beginning because 4D does not always do what you may expect. I recommend creating several test databases as described in this Part and experiment with different options. In some cases you will be pleasantly surprised, but in others you may get frustrated at first.

Part II will show how to:

• Create a New Database
• Set 4D Database Properties
• Create Tables
• Create Data Fields
• Create Forms
• Create a Value List (Choice List)
• Enter Sample Data

Database Creation Order

It will help the new 4D developer to understand the correct order of creating a 4D database. First a Table must be created. Next the Data Fields are created. Finally Input and Output Forms created. Calculations/Methods are created for the Data Fields.

Note: There are many other details that must be done, but the above are basic for what is covered in this Part.

This ordering is not arbitrary — it reflects how 4D’s structure editor is wired. A form is a layout of a table, so the table has to exist before the form can reference it. A data field belongs to a table, so the table must exist before the field. A calculation or method typically references fields, so those fields must exist first. If you try to work out of order, 4D will either stop you or force you to backtrack.

A useful mental model: think of the structure (tables and fields) as the skeleton and the forms as the skin. You cannot drape skin over a skeleton that hasn’t been built yet. Methods and calculations are the muscles that make the skeleton move — and they come last because they depend on knowing what the skeleton looks like.

Why the order matters in practice

• Tables first — a table is the container for a category of records (customers, invoices, products). Everything else hangs off it.
• Fields second — fields define what you actually store: a name, a date, a price, a status. Decide field types carefully here, because changing a field type later can invalidate existing data.
• Forms third — forms are how humans see and edit the data. You can build many forms against the same table (an input form, a list view, a printed report layout).
• Methods and calculations last — these automate behavior. Because they reference fields and forms, building them last avoids broken references.

If you are coming from a spreadsheet background, the temptation is to start typing data immediately. Resist that. In 4D, as in any relational database, the structure is the foundation, and the data is poured in afterward.

Going Back to Add or Edit a Table

You may wish to go back and add new Data Fields or a new Table or Form. This is not as straightforward as might be expected.

Let’s say you have been editing a Form and decide you want to add another Table. Normally, while in Design mode you would select “New Table” from the Structure menu. But wait, there is no Structure menu. What happened?

4D has changed the Design mode Menu Bar. You must close all the 4D windows (not 4D, just the open windows) and the Structure menu will reappear. Now you can see the Tables to edit or create new ones. You can also now edit and create data fields.

To edit or create new Forms, the Design mode Tools menu is always present so that should not cause confusion.

This is one of the single most common points of confusion for new 4D developers, and it is worth understanding why it happens rather than just memorizing the workaround. 4D uses a context-sensitive menu bar: the menus you see reflect the kind of window that currently has focus.

When a Form window is open, 4D assumes you are doing form work and shows you form-relevant menus. The Structure menu — which governs tables and fields — is only shown when no form (or other specialized) window is open.

Practical tips for navigating Design mode

• When in doubt, close everything. Closing all open windows returns you to the “home” state where the full Structure menu is available.
• Do not quit 4D. Closing windows is not the same as quitting the application. Your database stays open; only the editing windows close.
• Save before you close. If you have unsaved form edits, close the window deliberately and confirm the save prompt rather than force-quitting.
• Use the Tools menu for forms. Because the Tools menu is always present in Design mode, form editing is the one area that does not require the close-everything dance.
• Expect this to feel backwards at first. Most design tools keep a static menu bar. 4D’s dynamic menu bar is more context-aware, but it takes a session or two to stop being surprising.

Once you internalize the rule — the menu bar follows the window — the confusion largely evaporates. You stop hunting for a missing menu and instead ask, “What kind of window is open right now?”

Choosing Field Types and Value Lists

Although this Part deliberately avoids programming, two design decisions deserve real thought because they are hard to undo later: field types and value lists.

Field types

When you create a data field, you choose what kind of data it holds. The common categories in 4D (and in most databases of this era) are:

• Text / String — names, addresses, free-form notes. Flexible but not sortable numerically.
• Number — quantities, prices, IDs. Sortable and usable in calculations.
• Date — calendar dates. 4D stores these in a way that supports date arithmetic and sorting.
• Time — clock times and durations.
• Boolean — a yes/no or true/false flag.
• Picture — images or graphics stored with the record.

A practical rule: choose the most specific type that fits. If a value is a number, store it as a number, not text — otherwise sorting and calculations will behave unexpectedly. If a value is a date, store it as a date so 4D can sort it chronologically rather than alphabetically.

Value Lists (Choice Lists)

A value list (also called a choice list) is a predefined set of options that a user picks from instead of typing. It is one of the highest-value low-code features in 4D because it:

• Prevents typos — “Active,” “active,” and “Actve” become impossible.
• Speeds data entry — pick from a list rather than type.
• Enforces consistency — every record uses the same vocabulary, which makes reporting and sorting reliable.

Value lists can be static (a fixed list you type in, such as a list of U.S. states or a set of status codes) or dynamic (drawn from data, such as a list of existing customer names). For a first flat-file database, a static list is the simplest and most instructive starting point.

How to decide: field type vs. value list

Decision	Choose this when…	Watch out for…
Text field	The value is free-form and unpredictable	Cannot sort numerically; prone to typos
Number field	The value is used in math or numeric sorting	Do not store IDs as text if you’ll sort them
Date field	The value is a calendar date	Formatting differences between platforms
Boolean field	The value is genuinely two-state	Don’t use it for three-state statuses
Static value list	The options are fixed and known	Must be edited manually if options change
Dynamic value list	The options come from existing records	Depends on data being clean already

Entering Sample Data

Once tables, fields, forms, and value lists are in place, the final step in this Part is to enter sample data. This is not busywork — it is a validation step. Entering a handful of realistic records immediately reveals design problems:

• A field that should have been a number is accepting text.
• A value list is missing an option you actually need.
• A form is laid out in a way that makes data entry awkward.
• A date field is displaying in an unexpected format.

Entering sample data early, while the structure is still fresh and easy to change, is far cheaper than discovering the same problems after you have entered hundreds of real records. Treat the sample data as a test harness for your design.

Acknowledgments

Special thanks to: James Fortier for supplying some of the resources and helping proof read the document.

Copyright