HMGforum.com

Hi All,

Some problems were reported on data-bound grid with non-standard (contrib) rdds (sqlmix and pgrdd).

These rdds are great an involved a lot of work from its authors.

Sadly, they inherits some behaviors from SQL (the back-end database were the data comes from).

The problems are basically related to record modifying and adding.

For example, SQLMIX allows changes, but those changes affects only the local recordset (the local copy of the data from the server). Changing or adding records to the back-end table involves sending SQL commands to the server to achieve that.

Regarding PGRDD, it is more advanced and allows modify and append records, but the back-end table must have a primary key and when adding records, the first value to be replaced must be the key field (these insights are based on preliminary tests, so it could be wrong in some aspects).

Anyway is very clear that support for modify tables with data-bound grid for these rdds, will require specific code for each one and (maybe) new properties, to signal to the Grid, ie, what column is the primary key of the table.

So, at the moment, these rdds will be supported by data-bound grid, but modifying will not be allowed.

I've added adequate error checking for that. Those changes will be included in 3.0.22.

Thanks for the decision Roberto.

Hello Roberto,
Thanks a lot. This will clear some confusions
With best regards.
Sudip

Roberto Lopez wrote: ...
The problems are basically related to record modifying and adding.

For example, SQLMIX allows changes, but those changes affects only the local recordset (the local copy of the data from the server). Changing or adding records to the back-end table involves sending SQL commands to the server to achieve that.

Regarding PGRDD, it is more advanced and allows modify and append records, but the back-end table must have a primary key and when adding records, the first value to be replaced must be the key field (these insights are based on preliminary tests, so it could be wrong in some aspects).

Anyway is very clear that support for modify tables with data-bound grid for these rdds, will require specific code for each one and (maybe) new properties, to signal to the Grid, ie, what column is the primary key of the table.

So, at the moment, these rdds will be supported by data-bound grid, but modifying will not be allowed.

I've added adequate error checking for that. Those changes will be included in 3.0.22.

Hello Roberto,

I don't know SQLMIX. It it is unable to write into the backend, it does not seem very useful. But with PGRDD, it seems to me, that you are almost there.

PGRDD it is very sophisticated. Changes will automatically cause an update or insert statement to be sent to the database-backend. Pgrdd even automagically finds out, what the primary key is. I have some complicated tables and pgrdd does a very good job. Some of my tables even use three columns as primary key.

It works very well with all other HMG-controls and it is very very easy to port existing applications to postgresql.

I am simply amazed! Two years ago, when I started working on old clipper code (written by a student around 1987-1991, when I was still a kid), I never expected getting this far. My application is far from finished, but harbour and especially hmg did so much for me. The combination of hmg and SQL gives me the best of both worlds. I was able to convert a lot of complicated clipper code with lots of loops into short and powerful sql-statemets. Hmg made it possible to port some old console-based forms into beautiful windows application. And during the whole remodeling, the program stayed usable. I could go on about how great the combination hmg and postgresql is.

With version HMG 3.0.20, changing data in a grid worked and the pgrdd did change the values in the backend correctly. I tested it and it worked very well.The problem was that after the change was committed, the grid had to refresh the data and that is, where the error happened.

I did not fully understand, why I got my errors, but there are two major differences:

1. postgresql-tables don't have RecNos. Pgrdd emulates them. But every time it reopens a table, it assigns new recnos.
2. pgrdd does not have indexes.

The grid opens the data without any problem.
The grid writes the data without any problem.
It is only a problem of refreshing the grid.

Is it possible to simply reload the grid after every update or insert?

Thank you
Raumi

PS: Is anybody interested in a little howto with screenshots about postgresql an hmg? If you want to see how easy it is, I can write a litte howto-document, to get you started (downloading, installing, setting up of postgresql-server on your windows-machine and connecting it with hmg). Just let me know and I will do it.

Hello Raumi,

Please tell us how to work with PGRDD I am very much interested.

With best regards.

Sudip

I am very much interested, too.
Where I can find PGRDD?

Hello Raumi

Your offer is very much appreciated.

TIA
Angel

raumi75 wrote:
With version HMG 3.0.20, changing data in a grid worked and the pgrdd did change the values in the backend correctly. I tested it and it worked very well.The problem was that after the change was committed, the grid had to refresh the data and that is, where the error happened.

I've made a lot of tests.

I know that postgre rdd is very advanced and capable of change backend table data, but it performs very different that standard rdds in various aspects. This creates the problems with Grid.

As you said, is possible currently to change data on back-end table, but a lot of problems with refresh (and other things) needs to be solved and will require create specific code for it. Sadly, this is not a simple fix, so, until the new code be created and tested, edit, append and delete will be disabled for postgre.

The different nature of stateless data engines ( dql engines ) and online data ( dbfs) makes imposible a 1 to 1 paradigm shitf without making a lot of compromises.
As far as I know the only way to hace the best of both worlds is to enforce a serila field in postgresql called recno or similar set to primary key. On client side map all recnos in a recordset to an array or hash of recnos with an extra flag marking if it's updated or not and the grid must query every record as needed ( same tbrowse does on dbfs )
So to resume sql must return recnos and efective record must be read one by one as needed.

So we need 2 pgrdds: 1) as actual without updates 2) another one mapping recordsets to a hash of recnos and refrshing only updated ones.
The compromise: speed. And still there is to solve the problem of appends by other people in the net that involves our recorset

I hope I've explained myself well.

Regards
Angel

So nicely worded Angel.