FiveTech Support Forums

Hello friends,
Perhaps this also explains why DBF is often prematurely dismissed as "obsolete," even though it can still be highly performant in a modern architecture—especially when using CDX and clear access interfaces. I’d like to add a practical perspective from my own experience, which only became fully clear to me much later.

In the past—with classic DBF/NTX setups—work was heavily state-dependent:
You’d open a DBF, keep it open, work with fixed work areas, set indexes, and rely on an implicit context. This worked well in desktop environments but had very real technical limitations.

A concrete example from practice:
We had DBFs with many NTX indexes—10, 12, or even 15 were not uncommon. Each index meant a separate file, in addition to the DBF itself. Back then, we quickly hit limits like:

• Maximum number of open files
• Directory limits (e.g., 256 files—no longer an issue today, but a real constraint back then)
• High administrative overhead for opening/closing files
• Increased error-proneness in crashes or interruptions

In multi-user environments, this became critical:
A failed access could leave the DBF and NTX out of sync—reindexing was a daily routine.

What only became clear to me later:
The real problem wasn’t DBF itself, but the access model.

NTX implicitly assumes:

• A running process
• A stable state
• Files kept open for extended periods

But as soon as you move toward services, web applications, and stateless access (open → read → close), this model falls apart.

This is where DBF/CDX makes a crucial technical difference:

• One index file per table
• Multiple indexes as tags
• Fewer open files
• Clearer structure
• Far more tolerant of frequent opening and closing

If you take it a step further and use DBF via a microservice, the picture changes entirely. The client no longer sees any state—only requests and responses. Locking, index selection, and transactions are fully handled by the service.

Pros and Cons from Practice

DBF/NTX

Pros:

• Very simple model
• Fast in single-user operation
• Well-suited for classic desktop applications
• Low barrier to entry

Cons:

• One index = one file
• Many open files for complex tables
• Highly state-dependent
• Prone to errors during crashes
• Poorly suited for web, services, and parallelism
• High maintenance overhead (reindexing)

DBF/CDX

Pros:

• One index file per table
• Multiple indexes as tags
• More robust in multi-user operation
• Better encapsulation
• More service- and web-friendly
• Lower file and lock overhead

Cons:

• Slightly more complex setup
• Less transparent for developers accustomed to NTX
• Clean architecture required to fully leverage advantages

DBF via Microservice (CDX-based)

Pros:

• Clear separation of data and access
• Stateless clients possible
• Full control over locking and transactions
• No DBF dependency in the client
• Excellent performance with controlled data volumes

Cons:

• Higher initial effort
• Requires specialized architecture and operational know-how
• Not an "out-of-the-box" standard like SQL servers

In retrospect, I’d say:
Many problems we once attributed to DBF were actually architecture problems—not format problems.

A very good explanation, Otto.

I started myself with NTX and I ran into the problem of max 256 open files. Then I moved to CDX. Later I had files with more than 60 indexes, without any problem.

I have a table that's used daily and managed by DBFCDX with over 60 million records. It works like a charm. +++ Tengo una tabla usada todos los días y manejada por DBFCDX con más de 60 millones de registros. Funciona como un avión.

Hello Michel, thank you very much for your reply. May I ask if you are still working with DBF files? Best regards, Otto

Otto

I appreciate your comments on dbf and I want to make one further point .. In this age of Corporate database breeches .. I think is important as developers that when we develop Corporate ( or mom and pop ) applications we have to realize the portability of using DBF and all it takes is one data breach and an attacker can copy and extract the information from your dbf .. and there goes you data.. Same goes for Portable databases like MS Access .. and the Database password can be easily broken .. here are the latest database breeches just to show you how prevalent they are :

Recent data breaches in late 2025 and early 2026 include incidents affecting Match Group (Tinder, Hinge), Nike, Qantas Airways, DoorDash, Instagram (via a third-party database), and healthcare providers like SimonMed Imaging, with common causes being ransomware, third-party software vulnerabilities, and employee credential harvesting, impacting millions of users across various sectors like finance, healthcare, and retail.

When we develop databases we need to discuss database encryption .. for all portable databases .. to re-assure the Customer if their data gets stolen or copied by a malicious attacker there is an extra level of security that if you open a dbf or mdb .. trying to read the data is practically useless.

Good morning,

Yes, I am still using CDX. It is a very stable environment. Never had any problems in 25 years time. The only thing I stopped using is memofields. If you memfile is corrupt, your DBF is correpted too. I rather make very long fields which I use in stead of memofields. And that is working just fine.

Dear Rick, I also worked with Access databases for many years and used the Jet engine for my ASP web developments. Unfortunately, that was discontinued, and even today I’m not sure whether the product is still available in that form.

On the topic of encryption, I’ve been thinking about it a lot, but so far I haven’t come up with a really good solution.

Dear Michael, thank you very much for your reply as well. I remember that we’ve already talked about this topic once before. I personally no longer use memo fields either. Instead, I now link to individual JSON files. This gives me a bit of structure even for memo-like content — essentially a kind of extended DBF format that I’m currently working on.

One question I still have is about the actual maximum length of text fields in a DBF database. When I developed the PHP4DBF driver to access DBF files directly from PHP, I looked closely at the format, but I never really clarified — or was particularly interested at the time — how long a field is actually allowed to be. In theory, there’s nothing preventing the use of very long fields. After all, the data is always determined by the record offset plus the field length, so in principle it shouldn’t matter how large you define it.

By the way, have you already been on a skiing holiday in Tyrol this year?

Best regards, Otto