Skip site navigation (1) Skip section navigation (2)

Re: psqlodbc versioning

From: Mark Slagell <ms(at)iastate(dot)edu>
To: Dave Page <dpage(at)vale-housing(dot)co(dot)uk>, pgsql-odbc(at)postgresql(dot)org
Subject: Re: psqlodbc versioning
Date: 2004-07-08 16:01:26
Message-ID: 40ED6FD6.4010903@iastate.edu (view raw or flat)
Thread:
Lists: pgsql-odbc
Dave Page wrote:
> ...
> 
> WRT to the lock issue, I haven't checked, but I suspect that the driver
> doesn't report it because PostgreSQL simply waits for it to clear before
> continuing (or detecting a deadlock and aborting the transaction). I'm
> not sure that the driver is supposed to report it off the top of my head
> though.

Okay, I wondered if this would come down to the question of exactly what
is the odbc spec.

The application in question originally ran with a non-SQL database 
engine ("ProISAM") that suffered from table size limits.  The larger 
clients started moving to Oracle a few years ago as they outgrew those 
limits.  More recently, the vendor announced to all clients that they 
would stop supporting ProISAM entirely, and everybody had to either move 
to Oracle (big bucks) or MS SQL server, or Postgres, which they were 
just starting to support. I suspect they never did a lot of testing on 
postgres, just assumed they could make minor adjustments to their Oracle 
code and it would just work. And apparently Oracle's odbc driver does 
report row locks so the application can relay that information to the user.

We were one of the first clients to adopt postgres, and were surprised 
to run into this symptom.  I have users calling my beeper all the time 
saying the application is broken, essentially because they can't 
distinguish a record lock from the system being hung, and it's starting 
to drive me up the wall.

Obviously we're talking about some problematic application design. It 
relies too much, and too conservatively, on row locks.  If one user is 
looking at a client information screen (even if they aren't changing 
anything) no other users can work with that client in any way until the 
first user leaves that screen.  Bad things can happen when somebody 
walks away from their computer and goes to lunch.

Being unable to improve the application ourselves since we don't own it, 
and assuming we're not just getting a snow job about what odbc supports, 
I'd be pleased if we could promote adding lock reporting to the psql 
odbc interface -- even if that means expanding the spec a little to 
duplicate that part of Oracle's behavior which our vendor apparently 
relies on. (Or does that imply postgres-proper issues too, making the 
idea unworkable?)

A less desirable solution is to cough up the bucks and convert to 
Oracle. I'd have a pretty hard time selling that to our bean counters 
this year.

In a better world, we would ditch the vendor completely, but they 
monopolized this little corner of the market some time ago and no viable 
competitor has emerged yet.  It's an unwieldy legacy application that 
most of their clients are entrenched with -- and although some of them 
have better resources than we do, frustration abounds.

   -- Mark

In response to

Responses

pgsql-odbc by date

Next:From: Peter EisentrautDate: 2004-07-08 17:52:34
Subject: Re: Emergent: get table names from SageLine50 by ODBC
Previous:From: Local CuberDate: 2004-07-08 14:34:19
Subject: Emergent: get table names from SageLine50 by ODBC

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group