Hi Mike,

I haven't used PostgreSQL with ProIV but I have extensive painful experience with other databases 

Like you, it made absolutely no sense to me why a savepoint would be being created. I cannot see how that could be normal, indeed I cannot see any reason for it in any regular ProIV processing.  I have never seen that with Oracle or DB2.

I was about to suggest this might be an ODBC driver issue as neither Oracle nor DB2 use ODBC with ProIV, however.. I see you have already received an answer in the affirmative elsewhere viz:

http://postgresql.10...-td5782434.html

+1 to the PostgreSQL community

Did that in fact fix most of your problem, it would be good to know?

Hi Mike,

 

I haven't used PostgreSQL with ProIV but I have extensive painful experience with other databases 

 

Like you, it made absolutely no sense to me why a savepoint would be being created. I cannot see how that could be normal, indeed I cannot see any reason for it in any regular ProIV processing.  I have never seen that with Oracle or DB2.

 

I was about to suggest this might be an ODBC driver issue as neither Oracle nor DB2 use ODBC with ProIV, however.. I see you have already received an answer in the affirmative elsewhere viz:

 

http://postgresql.10...-td5782434.html

 

+1 to the PostgreSQL community

 

Did that in fact fix most of your problem, it would be good to know?

Hi Richard,

The same mailing list from the link you came across told me to try adding "UpdatableCursors=0" in odbc.ini. I did that and it made a huge difference.

I've only tested it in a few places so far but one of our reports went from taking 50 seconds to approximately 10 seconds. Looking at the log file created from Postgres, I saw that the number of save points being created as well as the number of queries against the system catalog (pg_class, etc) went down dramatically. I'm just waiting to hear back from ProIV support to get confirmation that this setting will not cause issues elsewhere.