In this thread I wish to discuss about my small experience in migrating from dbf based database to SQL based database with regard to HMG. So, this is not a full documentation and don't have a high hope. You will see my ignorance about both dbf and sql then and there. However, I think it may be helpful to someone who wishes to convert their project from dbf to SQL.
SQL is just a sophisticated extension of dbf if you ask me. If you know well about dbf and you enter the SQL world with a notion that it will be further complicated, you will be surprised. It is just simple and easy.
If you want to migrate from dbf to SQL your basic questions will be:
1. How much (time, money, energy) should I spend to modify my existing projects?
We have to consider two points here:
a. If you have a systematic plan and procedure about the migration it will be easy even though we have to alter all the source code files. Here you also have to note that it is not just like find and replace.
b. Once after starting migration you will be surprised to note that the number of lines related to dbf is less in a source code file when compared to other GUI/validation part. You will find a common pattern almost in every HMG prg file like,
i. prepare a form
ii. pool basic data in to the form
iii. allow the user to enter new data or modify some existing data
iv. validate the data
v. save the data in a particular manner
vi. take report
Once you find this pattern in your project again it will be easy to alter them.
So, the conclusion is, it is not impossible.
There are many value additions like concurrency, ACID compliance, unlimited user connections, enhanced and in-built security, proper handling of data, scheduled automatic backup, usage of views, triggers, constraints, procedures so on and so forth. One of the very important advantages is, we need not spend much time on validation of data. We can fix the constraints in the database model itself and forget it.
Regarding SQL Vs DBF there are many web sites discussing like this one. http://fox.wikis.com/wc.dll?Wiki~SqlVsDbfthis (It is a heated argument between SQL and DBF but the latest comment is in 2008!).
During the transition time, just like any other software migration, we have to run the projects in parallel and compare the results. One fine day after having passed all the tests, we can replace the dbf project with sql one.
As I had mentioned already you will find it very easy and simple if you know the dbf basics.