Neil Mellis

Mike,

No real gotchas with Postgresql. I did get caught out  when moving from 8.1 to 9.2 and experienced initial cache building on my whole inventory. which turned out to be a bad index that behaved differently between versions.

When creating/converting tables I don't use the script creator within Proiv as this is a bit loose I just define it properly in pgAdmin.

I chose to use Postgresql to reduce cost of deployment on smaller user systems and provide a cross platform compatibility for Linux and Windows. The use of a ISO SQL also means that an up scale to Oracle is pretty straight forward.

I also chose to hybrid my data between pro-isam and the database. Most new stuff is mainly DB and designed to take advantage of it. Legacy only gets migrated when I need it - usually for more efficient retrieval or during larger changes.

My application uses a blend of technologies for Proiv/java/C/php/javascript and postgress works very well here and this gives me a choice as trends/demands arise. Proiv is still the fastest method of development !

Mike,

Don't forget that proiv lock logic doesn't work with postgresql so any lock will result in a spinning session until the lock owner releases. NG were going to look into handling this but no news yet.

I ended up having to use a pro-isam lock file where I really need critical tables to be managed properly.

Doing this also has the advantage that you only have to 'B' mode the pro-isam file with the keys and the lock logic gives you an opportunity for the user to respond to the lock or a timed/count retry prior to any table access. The pro-isam file can double as an audit as Neil B has suggested.

 By using this method iscollect will clean up the pro-isam lock on a session failure no need for user/admin lock screens etc.