All the work to develop in SQL is very important and already comes a little late.
Yes, much of it is coming late, but mostly that is the fault of Alaska Software telling everyone to wait for PGDBE.
They started talking about this back in 2008, at my eXpress++ conference in Boise.
At that time, I was already working in SQL with ADSDBE.
I had a customer with a very large application originally written in Clipper.
It became an enterprise-level application with 350 workstations and 25 stores all connected to a single application.
I helped him convert the application to Xbase++ and built a framework that would combine the best features of ISAM and SQL.
This was soon after Sybase bought Extended Systems and they created Advantage Streamline SQL.
I tried to promote this idea back then but never got any backup from Alaska Software because they were developing their own SQL solution and it still does not work as well as ADSDBE, ODBCDBE or SqlExpress (3rd party product).
I think that PostGreSql is a good idea (mostly because it's free), but it was available in Xbase++ years ago via ODBCDBE or SqlExpress.
Alaska talked a lot about incorporating SqlLite into the language to provide SQL without the requirement of a server.
That is still not available, yet we have been able to do this for over a decade using ADSDBE and Local Server (adsloc32.dll).
I agree that it is late, but it is
not too late.
That is why I have been working on the SqlQuery project.
Many of my customers must maintain and grow their existing applications and they are finding it harder and harder to find Xbase++ programmers to write and maintain code. However, there are a plethora of programmers who know how to work in SQL and they can be a valuable addition to the development team.
SQL also is a simple fix to some data problems that are arising in legacy applications because the data set is growing too large to work reliably any more.
A case in point is Bobby Drakos taxi application which was failing on a regular basis several years ago due to the thousands of transactions that had to be added every day to a database. The old ISAM code could not keep up with the application in real time.
By rewriting the code to use SQL INSERT statements instead of Lock - append - write -unlock (the old way), there has never been another failure. Using SQL to archive old transactions and reduce the size of the file from 20gb to 10gb (annually) took minutes rather than hours and could even be done without shutting down the application.
I welcome you who have large applications using DBF files to get on board with ADSDBE. You don't need to change any of your code to get started. It will work better than before and it will give you a starting point for learning SQL. It will also allow programmers who work in any language to develop applications, reports or web interfaces that work with your DBF data.
