FiveTech Support Forums

Good points, Otto. You're right that the sample size limits the statistical validity of any conclusions. Silence in a polarized debate often reflects caution, not reality. Even without meeting formal survey standards, though, the responses give us some directional insight — as long as we don't overinterpret them. Appreciate you bringing the statistical perspective into this.

I’ll keep updating it if you think it’s worth it.

My current usage:
• DBFCDX

(with HDO)
• MariaDB
• SQLite / SQLite3MC
• SQL Server

Plan:

I am considering moving from DBFCDX to ADS for a large project that will require a significant amount of time to fully migrate to SQL.

My future idea is to eventually migrate from MariaDB to PostgreSQL :D

1. What databases do you currently use in your projects? (check all that apply)
   Dbf

2. What database would you consider for your next project or migration? (maximum 2 options)
   None

3. a) Complete and updated documentation
   b) Practical examples and use cases
   c) Access speed and performance

4. Time needed to set aside to learn new stuffs

MYSQL/MARIADB

Both Server and Embeded

Hi

• dbfcdx

• mysql/sqlite

• Robust transaction support, Practical examples and use cases, Integrated debugging tools

Postgresql

Thank you very much for your collaboration. We will now analyze the results and draw some conclusions.
8)

Morning !!!

We're using:

• Oracle (Core)
• SQL Server
• MariaDB
• PostgreSQL

Regards,

I had not seen this previously but will be happy to answer:

I use DBF/CDX. However, my reasons are very specific. Let me explain:

I have been building one primary ( for sale ) application over the past 44 years, and I have used DBF files. I started with the very earliest version of dBase, progressed through all versions, into Clipper, then FW, and now Harbour. I found the tools I used were very effective with DBF files, and performance was quite good for my clients.

I considered SQL, and even did some experimentation. However, there were some very key reasons I did not make a switch:

1). My clients were happy with the program, it was rock solid, and they had no interest in how the data was stored. 2). Sometimes files can be corrupted. There are tools to fix individual DBF files and I couldn't find any to do the same on SQL databases. 3). Sometimes a file couldn't be fixed. I have 200 total in my application. If only one is damaged, I can role it back to a previous backup of that file, and then only that one file needed to have newer records input. In my experience, it was usually a counter file or some other small one that could be updated in a matter of minutes. I included an editor for them to do that, although if a larger file ( ie. parts ) had to be reverted a day or two, they could quickly see what was missing and insert it. It's a method that was highly effective. With SQL the whole table would have to be rolled back to a previous date and all that data re-entered ( or at least when I made the decision ). 4). Due to my age, I really didn't want to embark on a lot of time revising all my code to use SQL. As a "senior citizen", priorities change and I wasn't interested in competing against sales teams and marketing falsehoods to gain new clients. Most of my clients have been with me for over 30 years, and they value the fact I answer their calls and handle all of their questions and issues quickly. As they retire, they sell their business to a larger corporation with its own system, or simply close the shop. Family is far too important to take time away to reprogram to a different database. That is just my reality. 5). Advantage Data Base Server was a very effective solution for fast networking and my clients with many workstations purchased that option. Of course SAAS bought it out, and like so many great technologies, they killed it. Having been in this industry since 1982, I have seen so many good technologies discarded to enrich certain companies by eliminating competition with their lesser quality products.

Survey numbers are nice, but they mean little unless they are viewed with the actual reasons. My using DBF doesn't mean it's better than alternatives. It just means it fit my needs, expertise, and future directions better.

Tim, Thank you for sharing your perspective - it's always valuable to hear from someone with such deep experience in the field. Your reasons make complete sense given your context, especially the long-term stability you've provided to your clients and your current life priorities. The approach you've taken has clearly worked well for decades. I appreciate you mentioning the corruption/recovery aspect. That's actually an area where modern databases have evolved quite a bit since you last evaluated them. Both PostgreSQL and MySQL now have sophisticated transaction logs and point-in-time recovery that can restore individual tables or even specific transactions without rolling back everything. It's actually more granular than the DBF approach in many cases, though I understand the appeal of the simplicity you describe. The main reason I ask about database preferences in surveys isn't to suggest everyone should switch - you're right that different contexts call for different solutions. I'm more interested in understanding what the active development community is gravitating toward, which helps shape priorities for tools and resources. Your setup sounds solid for your needs. I'm curious though - for those still early in their journey with Harbour/FWH, do you think starting fresh with SQL might offer them advantages, or would you still recommend DBF for most use cases? Thanks again for the detailed response.

Manuel,

I think the answer to that question really depends on the project.

Clearly SQL is universal and will open more doors because it is known to most of the development community using other tools. If the intent is to build a product to be well marketed, or to be positioned to be acquired by another company, I would absolutely say use SQL. Also, if it is for the web, most hosted services provide SQL, so that is an easy path. Also, if they want data to be shared by both the Apple and Windows ecosystems, then they need a common data source ( SQL ).

If the intended use is for quick solo projects that are not intended for global distribution, DBF is a fast and easy solution. There is no need for installing servers, etc. Most starting developers will not be going down this path. However, it is easy to learn and use, so they might study it on the side.

The other reason to study DBF is because many government and corporate data systems actually still use it. Most developers have no idea what it is. As contracts are awarded to upgrade those systems, a developer who knows both formats will be incredibly valuable because they will be able to organize, and then import, data from the old system to the new one.

Tim

Tim

I find using SQl to be a more desirable database for most corporate users .. and if you like the portability of .dbf you might want to look into MS Access .. Sql commands are standard and you can build your app initially with MS Access and with just a change in the connection string ( see below ) lets say from MS access to Sql Server or ( perhaps ) Oracle the sql code is the same .. and all you have to do is change the SQL Provider .. using and .ini file to define the sql source you want to use and all your Sql code works without any other code changes ...

If xDatabase = "A"// msaccess xPROVIDER := "Microsoft.Jet.OLEDB.4.0" xSOURCE := cDEFA+"\Vehicle.mdb" xPASSWORD := "xxxxxxxx"

Else xPROVIDER := "SQLOLEDB" // sql server xSOURCE := "RICKLIPKIN-PC\SQLEXPRESS" xCatalog := "vehicle" xUserId := "vehicleuser" xPASSWORD := "xxxxxx" Endif

So for example you can have the same application for "mom and pop" and have your .ini file point to "A" for MS Access otherwise ( in this case ) your app can be set to Sql Server for a Corporate Sql Server database for a Business.

The above mods can be modified in many ways .. again .. by just changing he "provider" you can use most any Sql database you want with little or no application code changes ...

And lets say you want to use temp .dbf\cdx for reports as well ...

Rick Lipkin

Hello

MariaDB PostgreSQL MongoDB ArangoDB SQL Server DBF/NTX

Regards Osvaldo Ramirez