January 07, 2008
Let's face it, Pragma 5 is an old product. The main problem of Pragma 5 are its databases.
PFM is OK, but it very much shows its age of almost 17 years and is not client-server.
Btrieve, as we still like to call it, has changed its name to Pervasive, is not as stable as it used to be and least but not last it is expensive, very expensive, I am told. It's origin goes back still to the days of Diplomat (Pragma 3).
It is fun to go back that far with some Logical brochures,
but not for a database. Today the most used databases are SQL in one of its many dialects. The most famous ones are Oracle, Microsoft SQL and of course PostgreSQL.
 |
Postgres has one big advantage: it is like Linux and does not belong to a corporation and is therefore free. |
 |
How safe is it to use PostgreSQL? Will it be here 10 years from
now? You can give it the same answer you would give to Linux.
While Oracle might spend all his money in the America's cup and Bill Gates give everything to charity. |
 |
Pragma 5 has been building front ends to applications successfully now for almost 10 years. Join the front end capability of Pragma 5 with the brute force and power of PostgreSQL and you get Pragma 6, the SQL tamer. |
 |
You will be able to program the frond end of applications, be it displaying say an address record or a sales invoice with the usual Pragma 5 speed and simplicity. Or a listing of all the invoices of the month of May to customers of Fort Lauderdale, Florida, if Florida still exists after all those hurricanes. The data necessary for these customer interface windows will come straight from PostgreSQL, thanks to a bunch of new verbs dedicated to PostgreSQL. And to top it off, you can display your data in a succulent pie chart. |
Pragma 6 and PostgreSQL are two different worlds that can share a common interface. In no way should one interfere with the other or do the other's job. PostgreSQL cannot be handled like the other file managers of Pragma. That would be much too restrictive and negate the purpose of using an SQL database.
Broadly speaking there are 4 kind of commands for PostgreSQL :
The queries that send data to the server and don't expect
any data back.
The data has to be stored in the database. The query and accompanying
data is in a text file form, and it is up to the user
to write the best query and send the data to the server in a meaningful way. Experience has shown that
every programmer wants to do it in his own way and I respect that. In the
tutorial I'll show you the very basics, but from there on read the PostgreSQL
manual. Pragma 6 will have one verb to accomplish this :
SQL SET
FILE STATUS and EXTERNAL ECHO will contain the tag of the query or problems, if any.
It would be useless to make various verbs that UPDATE, INSERT, COMMIT etc. Just to have P6 join "UPDATE" in front of a string that you have to create anyway. UPDATE in SQL is not just like a SAVE. You can UPDATE for instance one record or all the records of a table. The possibilities are endless. What is much more important is that you create your verbs with your queries, so that you don't have to reinvent them every time.
The queries that receive data from the server.
You want to have a look at some data and then, based on what that
data says, send some data back or make corrections to the data. The
query and the data is received in text form, but Pragma 6 will help you
by giving you the data in the most easy, convenient and yes, why not,
elegant way. Beware though, the old computer adagio is still very much true:
you send a garbage query and you will get garbage data back. Two
verbs will accomplish this:
SQL GET FIELD gives you a single field
into a noun
SQL GET gives you the whole query in a
temporary PFM file.
FILE STATUS and EXTERNAL ECHO will contain the tag of the query or problems, if any.
Again it would be useless to restrict you to a simple SELECT query. You can do yourself a simple SELECT * from tablename yourself, or if you are adventuresome you can join tables etc. to your heart's content. And again, encapsulate your queries into verbs.
Utilities
Some information that you will need is not easy to extract with a query
described above. For this there is the verb
SQL GET PARAMETERS will give you the
names of the column in a table or how many rows and columns were fetched with a
query and other information.
SQL CONNECT connects and disconnects you to
a database. Only used if in the middle of a Pragma 6 session you have to
change database or want to disconnect, since usually the opening of a connection
is handles when first using a SQL verb or utility.
FILE STATUS and EXTERNAL ECHO will contain the tag of the query or problems, if any.
The queries that usually an administrator handles.
These queries (an example is CREATE TABLE or CREATE USER) you should
do from the excellent PostgreSQL Administrator program, even though SQL SET
could handle them. It comes free with Postgres and will let you do all the things you can,
should or should not do (provided you have the rights). For Pragma that means, among other
things, that all the issues of security will not touch Pragma.
To sum it up.
For you all this means that you will have to become a PostgreSQL
expert. Sure. Do you still believe that there is such a thing like a
free lunch?
All of the above is nice and dandy, but your question will be how to migrate in a short (very short time) to PostgreSQL.
There will be some parts of your old programs that will have to be manually converted to put to good use the power of PostgreSQL. Other parts will have to be rewritten to make the most of the PostgreSQL power.