My mistake :-(
Appears my test program had both of its tests the wrong way around, so
after fixing and re-testing I can confirm that the behavior IS
consistent with what the meta-data states for both "own" updates and
"other" updates.
It also means my tests against MS SQLServer and IBM DB2 for the
"commercial" driver I'm using reveal that they don't support "own
updates visible", so congrats to the PG project for getting this support
in the driver unlike the competition!
Apologies to all.
Andrew
On 03/31/2011 11:20 PM, Oliver Jowett wrote:
> On 1 April 2011 03:20, Andrew Hastie<andrew@ahastie.net> wrote:
>> It appears that the PG driver returns the original rather than the updated
>> data values for an updatable ResultSet. This is where the updates are
>> applied to a single table ResultSet in a single transaction.
> That's not meant to happen. Do you have a testcase showing the problem?
>
>> INFO - Own updates visible for TYPE_SCROLL_INSENSITIVE = true
>> INFO - Other updates visible for TYPE_SCROLL_INSENSITIVE = false
>> INFO - Own updates visible for TYPE_SCROLL_SENSITIVE = true
>> INFO - Other updates visible for TYPE_SCROLL_SENSITIVE = false
>> If however you applied the row update using an SQL UPDATE on a separate
>> Statement as opposed to using the ResultSet.updateX() methods within the
>> same transaction, then you DO see the new value at step 8. I suggest both
>> techniques should yield the same results.
> That's also not meant to happen - the driver should behave according
> to what the metadata claims (notably, "other updates" are not
> visible).
> I think we need to see your code here.
>
> Oliver