TD-22588: SqlSetIsolationLevel noneffective with TD .NET

[giscon]

Hi,

SqlSetIsolationLevel ( hSql, strIsolation ) returns always FALSE with TD Build Settings to .NET when trying to set any Read Commited Isolation level.
Since the documentation is a bit ambiguous (the TD Help lists RC, R1, R2, R3 and the reference guide lists RC, RC1, RC2, RC3), I tried with all these strings, but always got FALSE as the return value.

Instead, any "older" Isolation level as CS or RR works and the return value of SqlSetIsolationLevel( ) will be TRUE.

However, with TD settings to a Win32 application, the function SqlSetIsolationLevel( ) will return TRUE also for the RC-Isolation Levels. This works for all above mentioned RC-Isolation-level-strings R1, R2, R3, RC1, RC2, RC3 and RC (whatever the last one somewhat undefined RC will mean).

TD63_SetIsolationLevel.zip

Regards
Günter
Giscon Systems GmbH

TD6.3 Update 2 Build 45680 (build Settings to .NET WPF Desktop)

[giscon]

Any news about that or has a TD-defect No. been logged meanwhile?

[giscon]

Unfortunately this bug still exists in TD6.3 SP1.

As described above, the bug occurs only with TD .NET, with TD Win32 it works.

Günter
Giscon Systems GmbH

[Mike Vandine]

Hi Günter,

This is very strange!!

In doing testing of this (TD6.3 SP1 and SQLBase 12.0), I can see the exact same thing. The bizarre thing is that with the Win32 version, the display on SQLBase 12.0 shows the various connections in the log, but with .NET the only thing that is shown is the very first connection and setting the isolation level to RL! No other attempts to set the isolation level are shown. Also, in debug in the TD application, the bOK for the WS32 version returns as a 1 and for the .NET it returns as TRUE or FALSE.

So, I really need to do some more testing on this and might need to get Development involved in this.

Hang in there with me!

Best regards,

[giscon]

Hi,
I did some more testing (using SqlBase 11.7 SP3) and watched the isolation level displayed in the SQL Base Command Center in Cursor Statistics.

Again, with TD switsched to Win32, all the calls of SqlSetIsolationLevel were successful (returnvalue TRUE) and I could see that the chosen value was also effective in the database. The folliowing values could be used as synonyms: R1 = RC1 ; R2 = RC2 ; R3 = RC3´
By the way, specifying RC (without the RC-level-number at the end) was the same as R3 or RC3. As expected, using a real wrong value (e.g. R9) caused an error.
So, all o.k. with TD Win32 and SqlSetIsolationLevel.

But with TD Build Settings to .Net nothing works correct with SqlSetIsolationLevel !
Calls with the "older" Isolation levels as CS,RR etc. will cause a returnvalue TRUE and all RC-values cause a returnvalue FALSE.
But in ALL cases, even if the returnvalue is TRUE, there is no effect for the database connection itself! In the Command Center (with refresh of course) I could never see any change of the isolation level, the initial value after the connect (here it was RL) was never modified.
And It doesn't matter whether the first call of SqlSetIsolationLevel after the connect is a call with CS, RR, RL or a call with an RC-Level, the behaviour is always the same.

Another difference between TD .Net and TD Win32 I observed
The initial isolation level directly after the SqlConnect (before any call of SqlSetIsolationLevel) was RR für TD Win32 and RL for TD .Net.
In the Cursor Statistics window I could initially see one row for the new connection if I used TD Win32
But there were initially two rows for the new connection if used TD switched to .Net.

Using the function SqlConnectDotNet instead of SqlConnect didn't make any difference regarding all the behaviour described here.

So, the only difference for the behaviour of SqlSetIsolationLevel under TD .Net with different isolation level values is, that the function will return TRUE for the traditional isolation levels and FALSE for any RC-Level.
But in all cases the function SqlSetIsolationLevel has no effect with TD .Net.

Regards
Günter
Giscon Systems GmbH

[Mike Vandine]

Hi,

Thanks for the update. I've been pulling my hair out on this one. It doesn't make much sense to me.

One thing that I *have* seen is that the call wo CS, RR, RL all returned TRUE with the .NET *even though I didn't have an obvious connection*!! No dbntsrv.exe was running...

I need to be doing some more testing on this!

Best regards,

[giscon]

Hi,
any news about this bug?
Has a bug fix been scheduled for the next Update / SP or will this function remain to be unusable with TD .NET ?

Regards
Günter
Giscon Systems GmbH

[Mike Vandine]

Hi,

Unfortunately I haven't gotten any further with this. Still pulling my hair out.

I think I need to have someone else have a look at this because it's very puzzling.

[Jean-Marc Gemperle]

Hi

I entered
TD-22588
TD WIN32 (OLEDB) / .NET SqlSetIsolationLevel failure for RC, R2, RC2

TD WIN32 is all fine when using native router, but when using OLEDB it shows the same issue as TD .NET ( using SqlConnect/SqlConnectDotNet/SqlCreateSession/Statement )
See attached snapshot.
The checkbox SqlConnect/Disconnect() is to test .NET connecting/setting isolation level/disconnecting as opposed to connect on time and test each isolation level using same connection handle.

Because WIN32 is all working fine when using regular connectivity ( not OLEDB showing same problem in WIN32 OLEDB ) and the EXACT same application compiled to .NET fails on some of the isolation level for me unless these are not supported by SB this appears to be a bug to me...

JM

[giscon]

Hi,
thank you for entering TD-22588, but remember that with TD .NET the function SqlSetIsolationLevel does not work correct for ALL Isolation levels, not only for the RC-levels.
Initially I was also bluffed by the return value of the function SqlSetIsolationLevel which was True for the "traditional" isolation levels as RR, RL etc. and False for the RC-levels.
But as described above, even if SqlSetIsolationLevel returns True, it has no effect to the real Isolation level on the database. That will never change when using the testcase program switched to TD .Net. In opposite, with the same program switched to Win32, all is ok.
( I tested all only with the native router. )
And as Mike reported above, the return value could even be True when no dbntsrv.exe was running...

So please correct the description of TD-22588
TD WIN32 (OLEDB) / .NET SqlSetIsolationLevel returns FALSE for RC1, RC2, RC3 (or R1, R2, R3, RC) and returns TRUE for the other Isolation levels but in all cases the Isolation level will not change for the real database connection.

You can watch this behaviour in the SqlBase Command Center, never a change with TD .Net and every change ok with TD switched to Win32.

Regards
Günter
Giscon Systems GmbH

[Jean-Marc Gemperle]

Hi,

I've updated the description to reflect yours and Mike findings...

TD-22588
TD WIN32 (OLEDB) / .NET SqlSetIsolationLevel not functional

Commenting that Command center does not show any changes when using .NET.

JM

[giscon]

Any news about it?
With TD6.3 SP1 Update 2 (Build 47957) the bug still exists.

Regards
Günter
Giscon Systems GmbH

[Mike Vandine]

FYI, this is scheduled for a fix in the TD6.3 SP2 release.

[giscon]

Hi,
although this bug is listed as fixed in the release notes for TD6.3 SP2, I cannot confirm this.

Unfortunately still the same behaviour with TD.Net as before (tested with the testcase uploaded in the initial post of this bug report).
SqlSetIsolationLevel returns FALSE for RC1, RC2, RC3 (or R1, R2, R3, RC) and returns TRUE for the other isolation levels as RR or CS.
But in all cases the isolation level will not change for the real database connection. The shown isolation level in the command center after the connect is RL and this will never change.

This behaviour does also not change if after each call of SqlSetIsolationLeve a new query is started
(Call SqlPrepareAndExecute, Call SqlFetchNext, Call SqlCommit).
Even the tries to set the isolation level to RR or CS (where the function SqlSetIsolationLevel returns true) have still no effect.

Best regards

Günter
Giscon Systems GmbH

Windows 7
TD6.3 SP2 Build 48583
SqlBase 12.0.1 10897

[giscon]

No reaction?
This bug is documented as fixed but I think it's not (see my previous post from Jul 13)!