TD6 SP2 Saving binary data in ORACLE 10g

[Thhi]

Hi,

were there any changes in TD6 SP2 regarding SalStrCompress?
We save binary data in an Oracle10g database using an external function and SalStrCompress.
In TD 5.x and 6.0 SP1 this works well. When we save data with SP2, and fetch them again, we get a damaged file.

If we fetch data (using SP2 app) saved with TD5 or TD6 SP1 app, the file is ok.

[Jeff Luther]

were there any changes in TD6 SP2 regarding SalStrCompress?

I don't see anything when I searched for SalStrCompress.

You will need to put a small test case together so I/we can test this. Ideally, a v5.2 test with SQL create/insert etc. in it, then fetch back to get the inserted value. What's the Oracle 10g column type you are using?

When we save data with SP2, and fetch them again, we get a damaged file.

Sure it is SalStrCompress(), and not SalStrUncompress() ? How do you know which might be failing? How is the file "damaged"? Cannot be uncompressed?

What if you have existing data from SP1 in the DB and fetch/SalStrUncompress(). Do those values look OK?

[Jeff Luther]

FYI, Thhi, I've moved this topic from Enhancements. You are reporting a problem so this this is the correct forum area for such reports. Enhancements are suggestions for improvements to TD.

[Thhi]

You will need to put a small test case together so I/we can test this. Ideally, a v5.2 test with SQL create/insert etc. in it, then fetch back to get the inserted value. What's the Oracle 10g column type you are using?

We are using BLOB.
See the test case.

Sure it is SalStrCompress(), and not SalStrUncompress() ? How do you know which might be failing? How is the file "damaged"? Cannot be uncompressed?
What if you have existing data from SP1 in the DB and fetch/SalStrUncompress(). Do those values look OK?

When I fetch existing data saving with SP1 or before, the PDFFile is ok.
When I try to open the uncompressed file saved with SP2 I get the message, that the file is damaged.

[Thhi]

Hi,

can nobody else reproduce the error in the test case?

Thorsten

[sadowsky]

Hi Thorsten,

we have a similar problem:
we compress a text and save it into a LongChar field. Until version 4.1 PTF2 it worked. With version 6.0PTF2 we get back a faulty text. With database SQLBase it still works.

We use the following procedure:

Call SalStrCompress (slpUADString)
Call SqlPrepareAndExecute (hSql1, 'UPDATE compress_long
SET text =: slpUADString WHERE mandant = 999 ')

Call SqlPrepareAndExecute (hSql1, 'SELECT text INTO: slpUADString
FROM WHERE compress_long mandant = 999 ')
Call SalStrUncompress (slpUADString)


After the SELECT the text is not correctly.

Best regards
Volker

[Jeff Luther]

For both of you: I suggest you break this problem down into 2 separate issues:
1) test read/compress --> uncompress on a string you read in off disk

And if that works, then:
2) test read/compress --> INSERT into DB --> fetch from DB --> uncompress

That will narrow down where the problem is, hopefully. Problem now is you might not be sure where the problem is: read off disk, compress, add to DB, fetch from DB, uncompress -- though there could be a coding or other problem for 1) and 2).

[sadowsky]

Hi Jeff,

i don't understand your replay. We develop with TD about 15 years and we know what we do. We have tested the problem in detail and found out that it is because of the connection to Oracel. A "test read/compress --> uncompress on a string you read in off disk" make no sense. As i write, we have no problem, if we write the data to SQLBase 8.5, 9.0, 11.5.

We modified the application of Thorsten : we write a text (e.g. " 1010101") and not a file into the database, if we read the data from SQLBase, then the result is correct, the same with Oracle give a wrong result.

If we write the data an fetch the data immediately from Oracle with "Call SqlSetLongBindDatatype( 1, DT_LONGBINARY )" than we get the error 1062. If we close TD6.0 and make the read directly, than there is no error but wrong data.

I hope that they can reconstruct the problem.

Best regards
Volker

[Thhi]

Hi,

I save a file with an app before TD6SP2. When I fetch this data (any Version ), the file is ok.

I save the file with an app TD6SP2, When I fetch this data, the file is damaged.

In our special case I can say that the EOF of the file is damaged.

Kind regards

Thorsten

[Jeff Luther]

VOLGER: It is confusing for me to try to manage parallel, but different issues in the same thread. Yours is a text problem and that is different, though related, to Thorsten's. Since he started this thread I would like to keep this thread an Oracle/Binary issue. So, let me ask you to start another thread here in Bug Reports with your issue. Thank for you for your understanding.

(BTW, sorry for any confusion. I was simply suggesting that if you think you have a SalStrCompress problem, then a simple app. of reading a binary file off, compressing it, then uncompressing and writing a 'new' version of the file back to disk will separate this issue from one where the real problem is, for example, the wrong Oracle column type.
Also, be sure NOT to take anything personally here! I don't have a list of who has programmed for how long, so if you have 15 years at it, great! I am trying to manage my own brain -- not always easy -- by keeping problem test cases simple, clear, testing 1 (one) specific thing if possible, always trying to narrow it down so we know what we are testing, there are no assumptions and when we find a problem we know specifically what and where it is. That's all.)


THORSTEN: Now to you...Since you started this thread, let's continue this thread as your topic. I've tested your app. Oracle BLOB test (using Oracle 11g, not 10g; I don't have 10g I can access to). Anyway, when I run your test (test_ora_lob60SP2.apt) I am able to create, read the PDF, compress and insert, then fetch and uncompress and save to newtest.pdf OK.

NewTest.zip

File opened with Acrobat fine.

Here's my version of your v6 test app:

test_ora_lob60.-JL-ForumVersion.zip

The only change I made is that you need to add '+2' to each of the SalSetBufferLength() calls. This is true for v5.2 and for v6. The 2 extra bytes are for the end-of-string char.

So, aside from using Oracle 11g & t he '+2' changes I cannot see why you are getting a corrupted file. That is why I suggested earlier to try this and ignore Oracle:
New TEST:
* read the PDF off disk
* compress it
* not uncompress it
* now write that to newtest.pdf

Is newtest.pdf correct? If yes, then SalStrCompress/Uncompress seem to be working. And that would tend to narrow your problem to (somehow) an Oracle issue.
If the new PDF is NOT correct, then zip this new test + the PDF and attach here so I can look at it.

[Thhi]

Hi Jeff,

thank you for the hint. Adding the 2 bytes were the solution.
Until TD6SP1 we didn't need them.

Kind regards

Thorsten