Forum > Databases

The current value of AutoInc fields in a TDbf table

<< < (6/6)

Not only. Also dBase III, dBase IV, FoxPro, VisualFoxPro, Clipper, etc... Each of them is slightly different.

Not to put too fine a point on it, but in dBase formats autoinc fields should be regenerated on import, which means you can never rely on the autoinc field value between different applications. The autoinc field is stored as an integer value, but afaik the last increment value is NOT stored.
I worked on PerfectView, a then well known dBase format database system in the Netherlands many moons ago. The behavior between dialects is always the same: on export/import you will loose the exact sync between the tables (the autoinc value itself should be considered opaque, on import autoinc will be rest,i.e. implementation detail, not for the user). dBase and family were never designed to be truly multi-user. It is a single user database, with some later bolt-on's to make it work somewhat multi-user. Apart from single user applications I would run away from that format and use something more modern.

To summarize: if you use ANY dBase format, don't rely on the exact value of the autoinc field for queries in a multi-user environment and local tables.
In the 2020's dBase and the likes should be considered an archaeological find.

Typically, multi-user access is accomplished via file locks and has been used extensively in Clipper applications. It worked quite well (especially with NetWare or SMB1) and still works fine if applications are running on the same machine, e.g. Terminal Server.
You're right - there is no point in using dbf files in large, multi-user applications today. But dbf is still widely used for data interchange.


--- Quote from: korba812 on November 04, 2021, 07:31:09 pm ---Clipper applications

--- End quote ---
Yes. But that works indeed the same as I described. Once exported/imported there is NO sync between autoinc fields on other Applications using the same tables.

The first version of the application that is using these tables is more than 20 years old. Gradually stuff got added. There is work on a webapp. That started quite some time ago, but 4 years ago in earnest. Unfortunately, it is far easier for one man to add something to that old app, than for a whole SCRUM team to add that same change to a webapp. Feature parity is still some way off. Then again, of course the webapp does things the old one cannot, like a shared database between different locations and seamless integration of other online services. And those two things become increasingly important.

And of course, far more developers have a job building that webapp :)

The power of FPC/Lazarus is that you can build something that works very fast, especially database applications. The problem is that people who programmed in Delphi get scarce and it is seen as something old and depreciated. It's better to use the development tools and environment everyone knows than lobby for the use of a better one they don't. And it has to run in a browser, of course. Distributing and installing applications automatically never got off the ground.

So, in time the old, file based databases will slowly disappear. But in the mean time, it's much easier to roll out applications if you don't need to install an SQL server at each location. And as webplatforms assume a single connection to the database with admin access, you are required to build a backend as well. Which requires rolling your own (AJAX) communications, etc. It's far more work.


[0] Message Index

[*] Previous page

Go to full version