Neil Mellis

Hi Dex,

you can print them out from the excelsso.ExcelWriter supplied with V8.2.

If the @ExcelWriter Nickname is missing then you can get this quickly by reloading the latest demo (Project Admin Tools)

Make sure your using an 8.2 release as this has the full SSO included.

The SSO Gallery in developer tools allows you to look at the SSO details and print them.

If you are creating your own nickname SSO from the virtual_machine/NorthgateVirtualMachine.jar then you will have to rekey/name all of the method parameters by hand.

This is a real pain as there is no copy or auto define !! 

Hi Lew,

Have been running 7.1.58.0 for 5 months in production which was deployed from a 7.1.46 export - no problems on 64 bit Linux EL6 not sure what your .2 release is though.

Have also migrated from 7.1.58 to version V8 and completed testing with no application issues - very clean.

All the best

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 !

Darren,

defiantly worth using if your application has some big recursive updates or reports. I saw 20% improvement in some of the banking tests I did here. The only down side is that complex screens with a lot call outs can hog memory a bit. It would be really nice if the cache could be flushed within proiv currently it flushes when full. I remember also setting up the environments dependant on user type - i.e. only allow big report/update users to use it. Moving some of these processes to batch and caching for batch processes only is also an option.

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.