4th Dimension Learning Basics

Key Takeaways

• Data entry in 4D happens exclusively through the Input/Detail form — the Output/List form is read-only and simply routes you back to the Input form when you interact with it.
• Switching between forms is a core navigation skill: press Enter to leave the Input form, and double-click anywhere on the Output form to return.
• Value lists (choice lists) are the mechanism that keeps data clean at the point of entry — they constrain what a user can type rather than relying on validation after the fact.
• The moment you save your first records, 4D creates the physical database folder and its supporting files on disk — this is the structure you will back up, move, and eventually deploy.
• Entering sample data is not busywork: it is how you verify that your tables, fields, forms, and value lists actually work together before you build anything on top of them.

Why Data Entry Is the Real Test of Your Design

Up to this point in the learning sequence you have created a database, set its properties, defined tables and data fields, built forms, and wired up value lists. Entering sample data is where all of those decisions meet reality.

A field that looked reasonable in the Structure editor can turn out to be the wrong type once you try to type a real value into it. A value list that seemed complete can turn out to be missing the one option a user actually needs. A form layout that looked balanced in the Form editor can turn out to be awkward when you are tabbing through it with a keyboard.

This is why experienced 4D developers treat the first data-entry pass as a design review, not a data-loading chore. You are not just filling a table — you are stress-testing the schema, the form, and the choice lists simultaneously. If something feels clumsy now, it will feel far worse once you have hundreds of records and downstream reports depending on it.

Entering Data: The Mechanics

Make sure you are in User mode before you begin. In 4D’s classic architecture, the environment distinguishes between Design mode (where you edit structure, forms, and code) and User mode (where you actually work with records). Data must be entered via the Input/Detail form. You cannot enter data on the Output/List form — that form is designed for browsing and listing, not editing.

If you try, 4D is forgiving about it: double-clicking on a data field or anywhere in the Output form simply switches you to the Input form. That behavior is intentional and worth internalizing, because it means the Output form doubles as a navigation surface.

Once you are in the Input form, entering data works much like any database application:

• Click directly on a field to place your cursor there.
• Tab through fields in sequence — this is usually faster than clicking, and it respects the field order you defined in the form.
• Pop-up lists appear when a field is attached to a value list; you click the item you want to select, and 4D writes that value into the field.

That last point is the payoff for the value-list work you did earlier. A well-built choice list means the user never has to remember the exact spelling of a category, a status, or a region — they pick from a controlled vocabulary.

This is the same principle that relational database theory calls a domain constraint, and it is one of the cheapest, highest-value forms of data integrity you can build. If you want the formal background, the Wikipedia article on database normalization explains why controlled values in lookup fields reduce redundancy and update anomalies.

Switching Between Input and Output Forms

Navigation between the two form types is deliberately minimal, and it is worth committing to muscle memory:

• From the Input form: press Enter to switch back to the Output form.
• From the Output form: double-click anywhere on the form to switch to the Input form.

There is a subtlety here that trips up newcomers. Pressing Enter in the Input form does double duty — it both validates/accepts the current record and returns you to the list. That means if you have typed something invalid (a value that does not match the field’s type, or a required field left blank), 4D may hold you on the form rather than letting you leave. Treat that as a feature: it is the database refusing to accept bad data, which is exactly what you want.

A practical habit: after entering each record, glance at the Output form to confirm the record actually appears and that the values landed in the columns you expect. The Output form is your fastest visual audit of what you just saved.

A Worked Example: Entering Your First Records

Suppose your sample database tracks contacts, with fields for a name, a category, and a region, and value lists attached to the category and region fields. Here is how a clean entry pass looks:

1. Switch to User mode.
2. Double-click on the Output form to open the Input form.
3. Click into the name field and type a value.
4. Tab to the category field. Because it is bound to a value list, a pop-up appears — select an option rather than typing.
5. Tab to the region field and select from its list the same way.
6. Press Enter to accept the record and return to the Output form.
7. Confirm the new row appears with the values you selected.
8. Repeat for several more records, deliberately varying the values so you exercise different list options.

Step 8 matters more than it sounds. If you only ever enter one category, you never discover that a second category is missing from the list, or that a field is too narrow to display a longer value. Varying your sample data is how you find those gaps while they are still cheap to fix.

What 4D Creates on Disk

When you save records, 4D materializes the database as a folder on disk containing the structure file, the data file, and supporting resources. This is the artifact you will eventually copy, back up, and deploy. Understanding that the database is a folder — not a single opaque file — is important for a few practical reasons:

• Backups must capture the whole folder, not just one file, or you risk a structure/data mismatch.
• Moving a database between machines means moving the folder intact and preserving its internal relative paths.
• Version control of the structure is possible, but the data file itself is not something you typically commit.

If you are coming from a single-file desktop database background, this folder-based model is one of the first genuinely different things about working in 4D, and it is worth understanding early. The broader concept of how database management systems separate structure from data is covered in the Wikipedia overview of database management systems.

How to Decide What to Enter as Sample Data

Not all sample data is equally useful. A short, deliberate set beats a large, random one. Use these criteria when deciding what to type in:

• Cover every value-list option at least once. This proves each choice is reachable and displays correctly.
• Include one edge case per field. A very long name, a value at the boundary of a numeric range, a blank optional field.
• Enter at least one record you intend to delete. You want to confirm deletion behaves as expected before real data exists.
• Vary the records so the Output form has something to sort and scan. A list of near-identical rows tells you nothing about column widths or readability.
• Keep the set small. Five to ten well-chosen records is usually enough to validate a design; you are testing the schema, not populating production.

This mirrors the practice that software testing calls boundary value analysis — testing at the edges of acceptable input, where defects cluster. The Wikipedia article on software testing covers the family of techniques this belongs to.

Common Pitfalls at This Stage

A few problems show up again and again when people first enter data in 4D:

• Trying to type on the Output form. It will not accept input; it will just bounce you to the Input form. This is by design, not a bug.
• Typing into a value-list field instead of selecting. Depending on how the list is configured, free typing may be rejected or may create an unintended value. Prefer selecting from the pop-up.
• Forgetting to press Enter. If you navigate away without accepting, the record may not be saved. Make Enter your habit.
• Assuming the record saved because the form closed. Always verify on the Output form.
• Entering dozens of records before checking the design. Fix the schema and form first, then bulk-enter.

Where This Fits in the Learning Path

This step — entering sample data — is the last of the foundational sequence: create a database, set properties, define tables, define data fields, build forms, wire up value lists, and finally enter data. Once you can reliably enter, view, and navigate records, you have a working 4D database and a mental model you can build on. Everything that follows — queries, reports, methods, and eventually deployment — assumes you are comfortable with this loop.

For developers coming from other platforms, it helps to know that 4D’s approach descends from the same relational tradition as products like Microsoft Access and FileMaker, but with its own language and its own form-centric workflow. The Wikipedia article on 4D (programming language) gives useful context on where the platform sits in the wider landscape.

Frequently Asked Questions

Why can’t I type data directly on the Output form?

The Output form is designed for browsing and listing records, not editing them. When you double-click a field or anywhere on the form, 4D automatically switches you to the Input/Detail form, which is where all data entry happens. This separation keeps the list view fast and prevents accidental edits while you are scanning records.

How do I switch back and forth between the Input and Output forms?

From the Input form, press Enter to return to the Output form. From the Output form, double-click anywhere to open the Input form. These two gestures are the core navigation loop in User mode, and they are worth practicing until they are automatic.

What happens if I press Enter with an invalid value in a field?

4D may hold you on the form rather than accepting the record, because the value does not match the field’s type or a required field is empty. This is the database protecting its own integrity. Correct the value and press Enter again to save.

Do I need to enter a lot of sample data?

No. A small, deliberate set of five to ten records that covers every value-list option and includes a couple of edge cases is far more useful than a large random batch. You are validating the design, not populating a production database.

What does 4D create on disk when I save records?

4D creates a database folder containing the structure file, the data file, and supporting resources. Because the database is a folder rather than a single file, backups and moves must capture the whole folder to avoid a structure/data mismatch.

Is entering sample data really necessary before building more?

Yes — it is the fastest way to confirm that your tables, fields, forms, and value lists work together. Problems that are trivial to fix now become expensive once queries, reports, and methods depend on the schema. Treat this pass as a design review, not a chore.