MySQL and SQLite are supported by Harbour long back and these libraries are officially included in HMG by Roberto Lopez from the version HMG 2.0. From then onwards, we could have HMG as the front end and MySQL/SQLite as the back end.

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?

1. Naturally this depends on the size and complexity of your project. You may be having a hundred .prg source code files in a big project running into thousands of code lines. Altering all these source code files will be a Himalayan Task.

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.

2. Is it worth? What value addition will this bring to a project which is already successful and matured?

Definitely. Otherwise, there won't be any question of migration and you won't be here at all!

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.

3. What to do during the transition period? Can there be a hybrid database management having both dbf and sql in a project which gives room for partial migration?

My suggestion is to go for a full database migration even though it is possible to hold some data in dbf and some in SQL. That is up to you to decide which tables are to be maintained in dbf and which in SQL servers.

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.

4. How steep is the learning curve?

Believe me it is not so steep. The actual expansion of SQL is Structured Query Language. But my expansion is Simple Query Language.

As I had mentioned already you will find it very easy and simple if you know the dbf basics.

If you have any other questions I will be happy to answer them. Otherwise, shall we move on?

East or West HMG is the Best.South or North HMG is worth.
...the possibilities are endless.

We can use HMG + Mediator +MySql, all our database commands remain the same viz. use, append, delete etc but the processing is done by MySql backend using Mediator and the application becomes truly RDMS.

We have best of both the worlds. Very little change in the programs and all the advantages of the SQL World.

Learning curve is minimal and Mediator for MySql is free.

If there is sufficient interest, I can post a small manual for the steps required.

We can use HMG + Mediator +MySql, all our database commands remain the same viz. use, append, delete etc but the processing is done by MySql backend using Mediator and the application becomes truly RDMS.

We have best of both the worlds. Very little change in the programs and all the advantages of the SQL World.

Learning curve is minimal and Mediator for MySql is free.

If there is sufficient interest, I can post a small manual for the steps required.

Warm regards,

Jayadev

Yes. That will be great.

East or West HMG is the Best.South or North HMG is worth.
...the possibilities are endless.