‎2008 Feb 29 11:47 AM
Hi there,
I need to share with you a problem which is going me crazy regarding IMPORT/EXPORT from Database clusters.
I have to backup contents from cluster PCL2 index B2 to a cluster-copy ZPCL2, same index.
So, structure are exactly equals, and I tried this:
-> get records from PCL2 by select on table-keys
<- insert fetched records into ZPCL2
No problem for that, after the select an INSERT ZPCL2 FROM TABLE <rec> works perfectly.
Now, there is the issue:
I wrote a little program which reads contents from Backup Cluster ZPCL2, using the IMPORT statement.
At import time, it abends with CX_SY_COMPRESSION_FAILED -> run-time error IMPORT_DECOMPRESSION_ERROR.
OSS Note 457835 talks about a fixed lock at read/write time of a Cluster table, but this lock still lives until the end of the session. This is not my case, I'am running two different programs and so two different sessions.
So i tried out this, in the backup program:
-> select from pcl2 -> IMPORT of data -> EXPORT of data in ZPCL2.
And the reading program now works...
Seems that the system uses a compression algorithm that is different table by table and then data compressed for table PCL2 cannot be decompressed if copied in an another table...
Anyone knows something???
‎2008 Feb 29 12:28 PM
The behaviour you describe makes sense to me - as we know that cluster tables are different. The SAP documentation says: Besides the actual data values, the data string contains information on the structure of the data and which table it comes from.
This may be why your straightforward SELECT/INSERT failed. The structural information was inconsistent with the new table. What would be interesting, would be to see the hex of the VARDATA field for apparently identical records in each table.
matt
‎2008 Feb 29 12:28 PM
The behaviour you describe makes sense to me - as we know that cluster tables are different. The SAP documentation says: Besides the actual data values, the data string contains information on the structure of the data and which table it comes from.
This may be why your straightforward SELECT/INSERT failed. The structural information was inconsistent with the new table. What would be interesting, would be to see the hex of the VARDATA field for apparently identical records in each table.
matt
‎2008 Feb 29 12:54 PM
Ok, thank you so much Matt, now it makes sense!
And I can confirm you that identical values are written in backup cluster with a different HEX..maybe I should understand the problem before...
Kind regards,
Roby.
Edited by: Roberto Pagni on Feb 29, 2008 2:01 PM
‎2009 Jul 24 10:27 PM
Hi,
Do you have the sample code what you used for both import and export data into cluster B2