4th Dimension Learning Basics

This series is designed to help those who are coming from FileMaker Pro or who have some database design experience with another application. In this series, whenever “4D” is used, it is referencing “4th Dimension” and whenever “FMP” is used, it is referencing “FileMaker Pro.”

Perhaps the biggest hurdle coming from the world of FMP is that 4D is fundamentally different. The basic philosophy of the program is different. Terms are different. I will try to ease the reader into 4D by explaining how things relate between 4D and FMP. However, some of those things are very difficult or impossible to relate because they are unique to each product.

References for FMP will be for version 5.0.x and the Standard Edition of 4D version 4.6.x.

Note: The current suggested retail price for FMP 5.0 is $249 and for the 4D Standard Edition is $349. Both 4D and FMP are cross platform. Both work on Macintosh and Windows systems. Both have Web capabilities.

Part I will provide a bit of history for both FileMaker and 4D. It may be interesting to note that both 4D and FileMaker originated on the Macintosh and at about the same time (mid-80’s). Part I will also cover, not in too much detail, the following:

• System requirements
• Program structures
• Networking differences
• Differences in the runtime versions
• Compiler
• Web Hosting
• Data Charting
• Plug ins
• Tools/Utilities
• Resources
• Other 4D URLs

Note: The following order and contents of each Part are tentative.

• Part II will cover creating a simple 4D program
• Part III will cover Custom Menus
• Part IV will cover Methods
• Additional Parts TBD.

Key Takeaways

• 4D and FileMaker Pro both grew out of the mid-1980s Macintosh database scene, but they solve the same problems with very different architectures.
• The hardest part of moving from FMP to 4D is not syntax — it is the underlying philosophy of how data, structure, and code are separated.
• 4D exposes a true relational engine, a programming language (the 4D language), and a compiler, whereas FMP historically emphasized a single-file, layout-driven model.
• Terminology differs sharply between the two products, so learning the 4D vocabulary is a prerequisite to reading any 4D documentation.
• Cross-platform support and Web capability exist in both products, but the way each delivers them — runtime, compiler, and plug-in model — differs significantly.
• This Part I is a map of the terrain; the hands-on building starts in Part II.

Why 4D Feels Different From FileMaker Pro

If you have spent years in FileMaker Pro, your mental model of a database is probably built around a single file that contains tables, layouts, scripts, and relationships all in one place. You open the file, you see a layout, you click into a field, and you are working. That model is convenient and it is one of the reasons FMP became so popular with small teams and citizen developers.

4D asks you to think differently. In 4D, the structure of the database (tables, fields, relations) is defined in a separate structural context from the forms (the user interface) and from the methods (the code). This separation is closer to how traditional client/server relational databases are organized, and it is the single most important conceptual shift a FileMaker developer has to make.

A useful way to frame the difference:

• FileMaker Pro tends to be document-centric. The file is the application.
• 4D tends to be structure-centric. The structure defines the data model, and the application is built on top of it with forms, methods, and menus.

Neither approach is “better” in the abstract. FMP optimizes for rapid single-developer iteration. 4D optimizes for larger, more structured, more programmable applications — which is why it attracted developers who needed a real programming language and a compiler.

A Short Shared History

It is worth pausing on the fact that both 4D and FileMaker originated on the Macintosh and at about the same time, in the mid-1980s. That is not a coincidence. The original Macintosh created a new market for desktop database tools that could be used by individuals and small businesses rather than by mainframe operators.

FileMaker began as a Macintosh product and was later acquired and developed by Claris (a spin-off of Apple), which is why so many long-time Mac users associate FileMaker with the Apple ecosystem. 4D was developed by ACI (ACI US in the United States), and it grew into a cross-platform development environment with its own language and compiler.

Both products survived the transition from classic Mac OS to Windows and to modern operating systems, and both added Web capabilities. That shared lineage is why a FileMaker developer can often read 4D documentation and recognize the problems being solved, even when the solutions look unfamiliar.

System Requirements and Cross-Platform Reality

Both 4D and FMP are cross platform. Both work on Macintosh and Windows systems. Both have Web capabilities. That much is shared.

Where they diverge is in what “cross platform” means for the developer. In a FileMaker world, you typically develop on one platform and the same file opens on the other, with layouts that adapt. In 4D, cross-platform development is more explicit: you are building a compiled or interpreted application that must be deployed to each target platform, and you need to be conscious of platform-specific behaviors, file paths, and interface conventions.

Practical guidance for the developer coming from FMP:

• Decide your deployment targets early. If you only ever deploy to one platform, you can ignore a lot of cross-platform nuance. If you deploy to both, plan for it from the first form.
• Test on the “other” platform before you are deep into the project. Cross-platform issues are cheap to fix early and expensive to fix late.
• Understand the runtime model. 4D distinguishes between the development environment and the deployed runtime, which is a concept FileMaker developers often meet for the first time here.

Program Structures: How the Pieces Fit Together

This is the section that most repays careful reading, because it is where the philosophy difference becomes concrete.

In 4D, the major structural pieces are:

• The structure — the definition of tables, fields, and relations. This is your data model.
• Forms — the user interface. Forms are attached to tables and are the equivalent of FileMaker layouts, but they are more explicitly separated from the data.
• Methods — the code. 4D has a full programming language, and methods are where logic lives.
• Menus — custom menus, which Part III of this series will cover in detail.

In FileMaker Pro, these concerns are more blended. A layout can contain both presentation and logic (via script triggers and calculations), and the file itself is the container for everything.

The practical consequence is that in 4D you will spend more time designing before you building. That feels slower at first and faster later. FileMaker rewards jumping straight in; 4D rewards planning the structure first.

A rough comparison:

Concern	FileMaker Pro (5.0.x)	4D (Standard Edition 4.6.x)
Data model	Tables and relationships inside the file	Structure defined separately from UI
User interface	Layouts	Forms
Logic	Scripts and calculations	Methods (full language)
Menus	Built-in menus, limited customization	Custom menus (covered in Part III)
Deployment	Open the file	Runtime and compiled deployment options
Extension	Plug-ins	Plug-ins

Networking Differences

Networking is one of the areas where the two products diverge in ways that matter to real deployments.

FileMaker Pro’s networking model is built around opening a shared file over a network, with FileMaker Server or peer-to-peer sharing handling concurrent access. It is designed to be simple: you share a file, others open it.

4D’s networking model reflects its client/server heritage. 4D applications are typically deployed as a client connecting to a server process, and the developer has more control — and more responsibility — over how data moves between them. This matters because it affects performance tuning, record locking behavior, and how you design forms that display large record sets.

For the developer coming from FMP, the key questions to ask are:

• How many concurrent users will actually connect?
• Will the application run over a LAN, a WAN, or the public Internet?
• How much data will each form pull across the network, and can that be reduced?

These are questions FileMaker developers can often defer. In 4D, they tend to surface earlier.

Runtimes, the Compiler, and Why They Matter

Two of the most distinctive 4D concepts — and two of the least familiar to FileMaker developers — are the runtime and the compiler.

A runtime is a version of your application that can be distributed to users who do not own the 4D development environment. This is how 4D developers ship standalone applications. FileMaker has an analogous concept in runtime solutions, but 4D’s runtime model is more central to how the product is used commercially.

The compiler takes your interpreted 4D code and compiles it into a faster, more protected form. Compilation is not just about speed; it is also about protecting your source code when you distribute an application. For developers who have only ever worked in FileMaker, where the file is the application and the source is effectively the file, this is a genuinely new idea.

How to decide whether to compile:

• Compile when you are distributing to end users and want performance and source protection.
• Stay interpreted during development, where the faster edit-test cycle matters more than raw speed.
• Plan for compilation early, because code that compiles cleanly is usually better-structured code.

Web Hosting, Data Charting, and Plug-Ins

Both products have Web capabilities, but they approach the Web differently. FileMaker’s Web publishing historically emphasized serving layouts to a browser. 4D’s Web capabilities are tied into its language and its server, which gives developers more programmatic control over what is served and how.

Data charting is another area where 4D developers historically reached for plug-ins and external tools to render graphs and reports. If charting is important to your application, evaluate it early rather than assuming it is built in.

Plug-ins exist in both ecosystems. In FileMaker, plug-ins extend the calculation and scripting engine. In 4D, plug-ins extend the language and can hook deeply into the application. The practical advice is the same in both worlds: prefer built-in capabilities where they exist, and treat plug-ins as dependencies you must maintain across versions.

Tools, Utilities, and Resources

A few habits separate developers who thrive on 4D from those who struggle:

• Read the official documentation first. 4D’s documentation is the authoritative source for the language and the structure model.
• Use the developer community. Discussion lists and user groups were, and remain, where practical 4D knowledge lives.
• Keep a personal library of methods. Because 4D code is text-based and reusable, a well-organized method library pays off across projects.
• Learn the vocabulary deliberately. Terms like structure, form, method, and runtime have specific meanings in 4D that differ from their FileMaker counterparts.

For broader background on the relational model that underlies both products, E. F. Codd’s original work on relational databases remains the canonical reference, and the Wikipedia article on the relational model is a reasonable starting point. For the history of the Macintosh platform that gave rise to both products, the Wikipedia article on the Macintosh is useful context. For general database terminology, the Wikipedia article on database management systems is a helpful orientation.

Acknowledgments

Special thanks to:

• Brendan Coveney, President ACI US, for his help with the history of 4th Dimension.
• Will Porter of POLYTROPE SOLUTIONS, Houston, Texas, The XXII Group, for his help proofreading and keeping me on the straight and narrow.
• James Fortier for supplying some of the resources and helping proofread the document.
• Douglas Blew for suggestions.
• Jim Staples of ACI US, Inc., Macom/Press Relations, for proofreading and offering comments.
• David Graham for designing the web and PDF layouts for this guide.

Frequently Asked Questions

Is 4D basically the same as FileMaker Pro?

No. Both are cross-platform database products that originated on the Macintosh in the mid-1980s and both have Web capabilities, but their underlying philosophies differ. FileMaker Pro is document-centric, where the file is the application, while 4D separates the data structure, forms, and methods into distinct concerns. That separation is why 4D feels more like a traditional development environment.

Do I need to know a programming language to use 4D?

You can build simple things without deep programming, but 4D’s real power is in its language and its methods. Coming from FileMaker, where scripts and calculations cover a lot of ground, you will find that 4D expects you to write more code for equivalent functionality. The payoff is more control and better structure for larger applications.

What is a 4D runtime, and why does it matter?

A runtime is a distributable version of your application that users can run without owning the full 4D development environment. It matters because it is how 4D developers ship standalone applications to end users. FileMaker has a similar concept, but in 4D the runtime model is more central to commercial deployment.

Why would I compile my 4D application?

Compilation improves performance and protects your source code when you distribute the application. During development you generally stay interpreted for a faster edit-test cycle, and you compile when you are ready to ship. Code that compiles cleanly also tends to be better organized, so planning for compilation early is worthwhile.

How different is networking between 4D and FileMaker Pro?

FileMaker Pro’s networking is built around sharing a file, with FileMaker Server or peer-to-peer sharing handling concurrent access. 4D’s networking reflects its client/server heritage, giving developers more control and more responsibility over how data moves between client and server. That affects performance tuning, record locking, and how you design forms that display large record sets.

What will Part II of this series cover?

Part II will cover creating a simple 4D program, walking through the process from structure to form to method. Part III will cover Custom Menus, and Part IV will cover Methods in more depth. Additional parts are to be determined, and the order and contents of each part are tentative.

---

Copyright