TD-3927: SP2 TD5.1 Oracle native, Fetch into Long String not fixed

[johi]

Here I am creating a new topic as suggested by Ana.

I reported this bug in October

It got its first bug number.
You should see TD-3927 fixed in the december patch (Jean-Marc Gemperle)
With SP1, SqlFetchNext into Long String once more failed with Oracle native router with different symptom.
A new bug number was assigned: TD-4181 and appeared on "Final Fixed defects" for SP2.
With SP2, SqlFetchNext into Long String still fails with Oracle native router.

[johi]

Hi Chris,

Sigh, not true. We spent a good deal of time testing all of the native routers. I can't imagine why we missed this, especially after it was confirmed fixed. Our fault, and I'll try to figure out what went wrong.

I have an idea what might have gone wrong.
If you define an odbc database with the same ID as the Oracle SID, this interferes with Oracle native router.
So in order to test with pure native Oracle router, you have to remove the odbc entry!

[Jean-Marc Gemperle]

Hi Johi,

Most important IMO is that WE both agree and see the problem and we do confirm the issue in SP2 as

TD-4181 (re-open)

This is not fully fixed : Now the data comes up fine (SP2), but received string is not terminated properly, so we can still see the bug.

This bug is to put in correlation with
TD-3927
Corrupted strings while reading LONG VARCHAR, some string cannot be concatenated

Because we assumed this "similar" with ORACLE as with SQLBASE

SqlFetchNext: Incorrect BufferLength in Long String
by johi on Wed Oct 24, 2007 9:50 am

Similar problem with SqlBase:
https://support.guptatechnologies.com/supportforum/v ... .php?t=740Joejohi

TD-3927: Shows the same problem as TD-4181 (received string is not terminated properly). The test case and defect got fixed specific to SQLBase....

So this is what I believe happen....

ODBC could have come in the way indeed...but we know about it, I'm generally carefull about that as I know SQLODB32.DLL get loaded on the flly even if not defined in SQL.INI and might connect to a DSN having the same name as a router remotedbname....

So for me the over all issue whas 1 the assumption of TD-3927 is a similar issue with oracle then the regression of UTF8 TD-4181 that hidden your main issue

Cheers
Jean-Marc

[johi]

Hi Jean-Marc, thanks for your explanation.
I hope that before release of SP3 the fix will be tested against my testcase:

Oracle native router, Oracle column varchar2(2000), SqlFetchNext INTO Long String: sSelect,
verify SalStrGetBufferLength(sSelect) equals 2*(SalStrLength(sSelect)+1), e.g Byte length = 2 x (Char length plus trailing 0).

Because we have to move on with testing, we are adding the workaround
Set sSelect = SalStrLeftX(sSelect, SalStrLength(sSelect) )
to the code where a Fetch into long string occurs.
42 inserts done, in total 100+....

[Jean-Marc Gemperle]

NIELS

Sorry but TD-3927 is fixed against your testcase and this since TD 5.1 SP1
and now you say it is not fixed

.... I verified this just now. Your testcase
but also the testcase of the defect and it WORK FINE SINCE TD 5.1 SP1 and TD 5.1SP2.
This testcase CONCATENATES "Check string" and it failed to do the concatenation with TD 5.1 base release. Again I NO LONGER REPRODUCE THIS ISSUE.... Are you sur you checked your ORIGINAL TESTCASE?

So you assume that the JOHI thread is your issue now I really DOUBT BIG TIME ABOUT THAT unless you prove me otherwise..
There you say that

Database table with a key and a longvar field.
Inserting a record into this table with a long string bind variable of length > 32k causes a hard crash and if not the data are corrupted.

How is this related to TD-3927 again FIXED SINCE QUITE SOMETIMES and this Johi oracle thread???

does work fine for me for BINARY LONG...I agree with you TEXT LONG causes a problem there is one extra char at the end of the string when fetching, I noticed that too and a bug in on the way.....

But now telling on the forum TD-3927 is NOT FIXED for SQLBASE and YOUR TESTCASE IS WRONG for what I can see with your TESTCASE.... Please do not add extra confusion in Johi ithread that IMO as nothing to do with yours...

I understand your frustration about those issue. I like to ask you again to provide me a testcase or MODIFY mine to show me the exact problem you have (if this is not the new issue of having extra char fetched for that long varchar TEXT as indeed my testcase shows). Providing this will ensure your exact issue beeing fixed....as TD-3927 is from my test...

Regards

JM

[-tommi]

Hi.
A bit confusing to discuss about so many bugs in the same thread.

I'm confirming that concatenation bug still exsists in SP2, when using native Oracle router.
If we fetch varchar2(2000) to long string and try to concatenate something to it, it does not work.
As a workaround we are using SalStrReplace(strString, 0, 0, ''). Not very nice way and we have no idea how many places there are to fix.
So it would be very important to get this bug fixed.

-tommi

[Nils Jänicke]

Try this example. Here the string is much greater and then it crashes. Click Connect, Drop Table, Create Table, Inserts and then TD5.1 crashes. If not, the string got by "Clear ml1 and select" is not 100010 Characters, it holds the whole buffer size given by DBP_LONGBUFFER.

Nils