TD-15968: Data truncated(Oracle) in Long String TD6 Sp3

[Jean-Marc Gemperle]

Hi Again,

Yes there is a problem but I like to say *BUT* here :
Indeed the testcase truncates the LONG actually the testcase uses ORACLE LONG data type and not VARCHAR2 > 254 or CLOB...Now if you use those you would have no such problem (I tested it), not to say (ME) you should not use them but from ORACLE and MS LONG DATATYPE are deprecated since 9i...see

http://msdn.microsoft.com/en-us/library ... 10%29.aspx

Starting with the Oracle database 9i release, the LONG data type is deprecated. Oracle recommends using the LOB data types instead. Hence, when performing operations on the Oracle database using the Oracle Database adapter, we recommend using Oracle database artifacts that operate on LOB data types and not the LONG data type.

In any case this used to work in 6.0 SP3 or 5.2 SP3, broken in 6.0 SP3 EMP5361 a 5.2 SP4 and interestingly enough the SAME PROBLEM happens with LONG RAW as I entered recently an issue for that
TD-16022
ORACLE LONG RAW DATA truncation

You can test if you want with this : http://newforum.com/phpBB3/viewtopic.php?f=32&t=1735
It fails with LONG RAW but is OK with BLOB.
So it is the SAME issue and will add this TESTCASE (FOR TEXT) to this BUG and remove the "RAW" in description.

Basically we see problems with oracle LONG; but as far as I can see it is all OK with TEXT varchar2>254/CLOB and BINARY BLOB data types including concatenation now...

So I would recommend to use them and not the deprecated data types...soon or later will have problem if continue using them also I would believe from what I recall that you might see some performance issue with them...I'm not 100% sure but recall issues along those lines possibly depending the ORACLE client used..recall we certified 9i R2 but removed it...(as no longer supported by ORACLE) yet you still can connect with WIN32 using 9i but no one should do that...

Jean-Marc

[giscon]

Hi Jean Marc,

thank you very much for the detailed answer. For new applications we won't use the old deprecated LONG datatypes for Oracle-DB's.
But in older applications and data models the LONG type still exists and since these columns caused no problems - you know: "never touch a running system"
The different TD6 SP's and EMP's afforded some surprises with long varchar's (the list may be incomplete, only some points I know):

SP2
Oracle, SqlBase 8.5, 11.5, 11.6 o.k (but we could not use SP2 because of other bugs)

SP2 EMP 5347
Oracle: o.k.
SqlBase 8.5, 11.5: o.k.
SqlBase 11.6: buffer 2 bytes too short (null bytes missing) --> concatenation problem.

SP3
Oracle: truncation bug is new
Sqlbase 8.5, 11.5: still o.k.
SqlBase 11.6: buffer still 2 bytes too short --> concatenation problem

SP3 EMP 5361
Oracle: still the truncation bug, additionally the buffer for the truncated value is now 2 bytes too long
SqlBase 8.5, 11.5: buffer 2 bytes too long --> concatenation problem
SqlBase 11.6: o.k.
SqlServer (nvarchar): buffer 2 bytes too long --> concatenation problem


The migration of Oracle databases from LONG to newer datatypes as CLOB, BLOB etc. is clearly recommendable, but the fixing of the truncation bug (as I read from your reply is TD-16022 the relevant bugnr) will be appreciated nevertheless.

And the concatenation problems because of wrong buffer length should be fixed in the next EMP as you wrote, hopefully for all the above named databases.

Best regards
Guenter

[Sunil]

TD-15968 still unsolved, I am receiving truncated long string text into multiline text.

"TD 6.0SP2 Build 24565 April 1, 2011 sqlora32.dll which is already sended to support is working fine."

further request to Unify to fix TD-15968 defect on urgent basis.

Regards.
Sunil

[Mike Vandine]

Hi Sunil,

I will check this and get back to you. I believe that there were a couple of missed files in the build, one that might have been there to fix this exact issue.

[Mike Vandine]

Hi Sunil,

There was a problem with the build numbers on two files and thus they didn't get included in the EMP. One of those included the fix for this defect Please see the new topic in the announcements section about a refresh of the EMP.

Sorry for the inconvenience!!

Best regards,

Mike

[Sunil]

Hello mvandine,

I am sorry EMP5363 refresh is not still helps me , TD-15968 is still Unsolved.

Regards.
Sunil

[Mike Vandine]

Can you please tell me the build number of the sqlbapw10.dll that you have on your system after the install?

[Sunil]

hello.

6.0.3 S Build 25928 (SB10 13910) is build no of sqlbapw10.dll .

Regards.
Sunil

[Jeff Luther]

TD-15968 is still Unsolved.

For what database brand and version? You wrote able "(SB10)" -- does that mean SQLBase v10? Let us know, since we need more details, including the specific problem, the DB column type, etc.

I just tried the TD-15968 test case with my local SQLBase v11.6 (installed with v6) and the test works OK. I will attach it for you to try. My test connects to local ISLAND and runs OK. Click connect, then Create Test, then Select Text.

JL_TestEMP5363-SB116-ISLAND-OK.png

[Jeff Luther]

Hi, again Sunil -- sorry for my confusion. Mike V. reminded me that earlier in this thread you had mentioned Oracle as the DB backend. Either 10g and/or 11g.

I tested using that test case I attached previously to test the appl. with both Oracle 10g and 11g. Here's what I find:

* If the long string DB column type = LONG VARCHAR then Yes, I see the truncation problem. Is that the DB column type you have?

The problem is that this is an obsolete column type, as indicated on this Oracle Data Types page:
http://download.oracle.com/docs/cd/B283 ... tatype.htm

and specifically this Note here: http://download.oracle.com/docs/cd/B283 ... .htm#i3056

Note:
Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB) instead. LONG columns are supported only for backward compatibility.

LONG VARCHAR is not a correct data type for Unicode/double-byte string data.

See here for the Oracle data types: http://download.oracle.com/docs/cd/B283 ... .htm#i3253
because when I changed the test case to create the DB table with either NVARCHAR2(2000) ("NCHAR and NVARCHAR2 are Unicode datatypes that store Unicode character data") OR NCLOB ("NCLOBs store Unicode national character set data")data types, the test runs fine. In fact, CLOB works too.

I'll attach a test that includes prompt for whether to create the table using LONG VARCHAR or NCLOB (you could change that to NVARCHAR2(2000) to test as well). It shows that LONG VARCHAR no longer works for Unicode data but NCLOB, CLOB and NVARCHAR2(2000) all do.

CONCLUSION: You will want to change your DB column type to one of the Unicode-supported Oracle types.

[Sunil]

hello Jeff.

Please clarify, sqlora32.dll build 24565 is working fine with Long datatype and sqlora32 build 25928 is not working. I have gone through link also. Please clarify , why these two build both from unify handling Long datatype incorrectly , I don't think , oracle dropped this datatype recently.


Regards.
Sunil

[Jeff Luther]

Well, thanks for the audit trail summary of when this worked and then it broke. We're in the process of sorting out internally and what looks to the problem you report with EMP5363: A fix for this Oracle/LONG issue didn't make it into the 5363 code thread, so what worked earlier now doesn't in 5363, as you report.

Right now it looks like they will sort this out internally and get a fix/correction in the next EMP, EMP5365, due out in a couple weeks I heard.

In terms of what I wrote yesterday about Oracle and LONG VARCHAR, that is still true. Oracle did not drop the column type; rather, they caution against using it at least for future DB tables. That's their Note:

Do not create tables with LONG columns. Use LOB columns (CLOB, NCLOB) instead. LONG columns are supported only for backward compatibility.

This is/was a fresh issue for me because I've dealt with 'old' LONG column type and 'new' Unicode strings before. LONG was originally designed to hold some set of 'single bytes' - be they binary bytes, like in a TIF file or (ANSI) characters which are single bytes. It is the 'new' Unicode/double-byte world that has Oracle recommending a LOB type, column types which support Unicode, as I saw yesterday in my testing.

CONCLUSION: EMP5365 will have a fix for this regression in EMP5363. And, as always, someone will announce when the EMP is available.