4th Dimension Learning Basics

The 4D platform — originally 4th Dimension, and still widely known by its historical name — stores an entire application’s data inside a single structured Data file. Understanding how Tables fit into that architecture is the foundation for everything else you will build: fields, forms, value lists, and eventually the queries and methods that drive a real business app. This section walks through creating your first Table, opening its properties, and naming it correctly, while explaining the reasoning behind each step so you can apply it confidently to larger designs.

Key Takeaways

• In 4D, all Tables live inside one Data file rather than in separate files as they do in FileMaker Pro (FMP). This single-file model is central to how 4D handles backup, deployment, and multi-user access.
• A 4D database supports up to 256 Tables, each with a maximum of 2 GB of data or roughly 16 million records.
• You create Tables from the Structure menu while in Design mode.
• To open a Table’s properties, you must double-click the Table name area specifically — clicking elsewhere in the Structure window will not open the properties dialog.
• The Table Properties window has three tabs; the defaults are safe for a first project, and the Table Name can be changed at any time.
• Naming conventions matter: choose clear, singular-or-plural-consistent names like “Customers” before you build forms and relationships on top of them.

Why Tables Matter in the 4D Data Model

If you come from a FileMaker Pro background, the mental shift is important. In FMP, each table historically lived in its own file, and relationships were managed across files. In 4D, the architecture is different: all Tables are stored in the single Data file. The Structure (your design — tables, fields, forms, methods) is kept separately from the Data (the actual records users enter), but every Table you define lives within that one Data file.

This design has practical consequences that shape how you work:

• Backups are simpler. Because the data is centralized, you back up one Data file rather than tracking many.
• Deployment is cleaner. You ship a structure and a data file, not a folder full of interdependent documents.
• Multi-user access is built in. 4D Server manages concurrent access to that single Data file, so you do not have to engineer file-locking schemes yourself.

The trade-off is that the Data file becomes the single point of growth. That is exactly why 4D imposes per-Table limits — up to 256 Tables, each capped at 2 GB or about 16 million records. For most small-team and departmental business apps, those ceilings are generous. But if you are designing something that will accumulate millions of transaction rows, you should think early about how you split data across Tables and whether you need to archive older records.

Creating a Table Step by Step

For this walkthrough we will create just one Table, which keeps the sample database easy to follow. The same procedure scales to many Tables.

1. Enter Design mode. Table creation is a structural change, so you must be in Design mode. You cannot add Tables while running the application in User mode.
2. Open the Structure menu. From the menu bar, select the Structure menu.
3. Choose “New Table.” This menu item adds a new, empty Table to your structure.
4. Locate the new Table in the Structure window. The Structure for Sample Database window (Figure 6 in the original walkthrough) displays your Tables. A freshly created Table appears as an unnamed entry.
5. Double-click the Table name area. This opens the Table Properties window (Figure 7).

That last step carries a caveat worth repeating, because it trips up newcomers: you must click on the Table name area and not elsewhere. The Structure window contains several regions, and only the name area responds by opening the Table Properties dialog. If nothing happens when you double-click, you are almost certainly clicking the wrong spot — move your cursor directly onto the Table’s name and try again.

Understanding the Table Properties Window

When the Table Properties window opens, you will see three tabs. The original guidance is to leave them at their defaults for now, and that is sound advice for a first project — but it helps to know what you are deferring.

• The Table Name field stays visible on every tab. This is a deliberate design choice: no matter which tab you are viewing, you can rename the Table. You can change the name at any time, so a name is never permanent.
• The other tabs control structural behavior — things like how the Table participates in the broader database and how its records are managed. For a single-Table sample, none of these need adjustment.

The important habit to build here is restraint. New developers often open a properties dialog and start toggling options before they understand what each one does. In 4D, as in most relational database design, the safest path is to accept defaults, get a working Table, and revisit advanced settings only when a concrete requirement forces you to.

A note on naming

For the Sample Database, name the first Table “Customers.” This is a small decision with outsized downstream effects:

• Be consistent about plurality. If you name this Table “Customers,” name the next one “Orders” and “Products” — not “Order” and “Product.” Consistency makes relationships and code far easier to read.
• Avoid spaces and special characters where you can, since Table names often appear in code and in generated queries.
• Name for the entity, not the screen. “Customers” describes a thing; “CustomerEntryScreen” describes a form. Keep those concepts separate.

Once you have typed the name, click Apply, then close the window using the upper-left box or the Done button. Your Table now exists in the structure and is ready to receive fields.

How Tables Fit With the Rest of the Database

A Table is only the container. The rest of your application builds on top of it in a clear sequence, and it is worth seeing the whole picture before you continue:

• Data fields define the columns — the actual attributes you store, such as a customer’s name, address, or account number.
• Forms are the user interface: the screens where people view and edit records.
• Value lists (choice lists) constrain and speed up data entry by offering predefined options.
• Sample data lets you test forms and lists with realistic content before going live.

Each of these depends on the Table existing first. This is why 4D’s design workflow is deliberately ordered: structure before interface, interface before data. If you try to build a form before the underlying fields exist, you will simply have nothing to bind to.

It also explains why the single-Data-file model matters so much. Because every Table, field, and record lives in one coordinated structure, 4D can enforce relationships and referential integrity across your whole application without you managing external files.

That is the same principle behind relational database management systems generally — the concept formalized in E. F. Codd’s relational model and now standard across products like Oracle Database, Microsoft SQL Server, and PostgreSQL. 4D applies that relational thinking inside a self-contained application file, which is what makes it approachable for small teams and citizen developers.

Practical Guidance for Scaling Beyond One Table

The sample uses a single Table for clarity, but real apps rarely stop there. As you add Tables, keep these criteria in mind:

Consideration	What to check	Why it matters
Table count	Stay well under the 256-Table limit	Leaves headroom and keeps the structure navigable
Per-Table size	Watch the 2 GB / ~16 million record ceiling	Large transaction Tables may need archiving or splitting
Naming	Consistent, entity-based, no stray characters	Affects code readability and relationship clarity
Relationships	Define links between Tables deliberately	Prevents orphaned or duplicated data
Growth plan	Decide early what gets archived	Protects performance as data accumulates

A useful rule of thumb: model one Table per real-world entity (customers, orders, products, invoices), then connect them with relationships rather than cramming everything into one wide Table. This mirrors the normalization principles taught in most database curricula and keeps your 4D structure maintainable as the app grows.

Common Mistakes to Avoid

• Clicking the wrong area in the Structure window. Only the Table name area opens Table Properties. This is the single most common stumbling block in this step.
• Renaming Tables late without checking dependencies. You can rename at any time, but if forms, methods, or relationships already reference the old name, you will need to update them.
• Ignoring the size limits until it is too late. The 2 GB / 16 million record cap per Table is generous but finite. Plan archival for high-volume Tables.
• Building forms before fields. The workflow order exists for a reason — define the structure first.
• Over-customizing properties on day one. Defaults are there to get you moving. Change them when a requirement demands it, not before.

Frequently Asked Questions

How many Tables can a 4D database hold?

A 4D database supports up to 256 Tables. Each Table can hold a maximum of 2 GB of data, or roughly 16 million records. For most departmental and small-team applications these limits are more than sufficient, but high-volume designs should plan for archiving.

Why can’t I open the Table Properties window?

You are almost certainly clicking the wrong part of the Structure window. The Table Properties dialog opens only when you double-click directly on the Table name area. Clicking elsewhere in the window does nothing, so reposition your cursor onto the Table’s name and try again.

Can I rename a Table after creating it?

Yes. The Table Name field remains visible on all three tabs of the Table Properties window, so you can change the name at any time. Just remember that if forms, methods, or relationships already reference the old name, you will need to update those references.

Do I need to change any of the Table Properties tabs?

Not for a first project. The original walkthrough recommends leaving the defaults in place, and that is good practice. The three tabs control structural behavior you will not need until a specific requirement forces you to revisit them.

How is a 4D Table different from a FileMaker Pro file?

In FileMaker Pro, tables historically lived in separate files. In 4D, all Tables are stored inside the single Data file, which centralizes backup, deployment, and multi-user access. This is the key architectural difference to internalize when moving between the two platforms.

What should I name my first Table?

For the sample database, name it “Customers.” More generally, choose entity-based names, keep plurality consistent across Tables, and avoid spaces or special characters since Table names often appear in code and generated queries.

Where to Go Next

With your first Table created and named, you have the container your application needs. The next step is defining data fields — the columns that give the Table its substance. From there you will build forms for the interface, wire up value lists to speed data entry, and finally enter sample data to test everything end to end. Each stage builds directly on the Table you just created, so take a moment to confirm it appears correctly in the Structure window before moving on.