CDPOS copy

[Former Member]

Hi,

after an upgrade/go-live, we had an issue with CDHDR/CDPOS - they were empty.

All new changes logged correctly so the only solution available to us (allowed here) is to create ZCDHDR and ZCDPOS for the old data from text file downloads and write a report to view.

Process followed:

1) CDHDR downloaded at DB level to RAR file

2) Created ZCDHR, basis uploaded the file to ZCDHDR - all records present

3) CDPOS is a cluster of CDCLS so downloaded CDCLS at DB level to RAR file

4) Created a ZCDCLS and ZCDPOS linked to it.

5) Basis uploaded the file to ZCDCLS

At DB level, all records are there - count(*) returns the correct amount but SE16 says 0 records.

And a SELECT in abap says 0 records.

Any ideas why the ZCDPOS link to ZCDCLS does not work?

Thanks.

[RaymondGiuseppi]

Look at data in (Z)CDCLS, look in hexadecimal mode at the first bytes in VARDATA, you should recognize "CDPOS" from 4th character '0043' '0044' '0050' '004F' '0053' + some spaces '0020')

You may try to update those values, but why did you remove CDPOS from upgrade, minimizing downtime ?

Regards,

Raymond

[Former Member]

Hi Raymond,

I'm not the basis guy. I 'think' it was a mistake on their part...they used SAP_ALL instead of the approved SAP profile which would bring the the CD* tables. It wasn't quite an upgrade...tried to keep my question as basic as possible. Moving from one instance to another.

If this wasn't a public forum, I'd be cursing right now!!!

Okay, I see that VARDATA and the HEX values.

So, I must replace CDPOS with ZCDPOS:

004300440050004f0053 with

005a004300440050004f0053

I'll try that and see what happens.

thanks.

[Former Member]

Hi Raymond,

I ran a program to change 6 entries in ZCDCLS for two batches. When I look at the table entries in ZCDCLS, the VARDATA looks correct. I put it through an online hex->string utility to make sure.

Problem is that when I try to look at these entries in ZCDPOS in se16 or via code (SELECT * from...) I get a short dump. For records that I have not updated, it still finds nothing. So, I suppose, that's kind of good news...at least it finds them.

I'm going to delete ZCDPOS and re-create to see if it re-creates the link to ZCDCLS.

Apart from that, can you think of what else could be wrong?

FYI:

DUMP during se16 (st22) :

An invalid request was made to the SAP database interface in a statement in which the table "ZTBC_CDPOS" was accessed.

At this point-->

SELECT * FROM ZTBC_CDPOS                     "client specified

                 APPENDING TABLE IZTBC_CDPOS

                 UP TO RSEUMOD-TBMAXSEL ROWS BYPASSING BUFFER

   WHERE OBJECTCLAS IN I1

   AND   OBJECTID IN I2

   AND   CHANGENR IN I3

   AND   TABNAME IN I4

   AND   TABKEY IN I5

   AND   FNAME IN I6

   AND   CHNGIND IN I7

   AND   TEXT_CASE IN I8

   AND   UNIT_OLD IN I9

   AND   UNIT_NEW IN I10

   AND   CUKY_OLD IN I11

   AND   CUKY_NEW IN I12

   AND   VALUE_NEW IN I13

   AND   VALUE_OLD IN I14.

   CATCH CX_SY_DYNAMIC_OSQL_SEMANTICS INTO xref. <<<<<<<<<<<<<<<<<

[RaymondGiuseppi]

Also insure that when converting 'CDPOS     ' to 'ZTBC_CDPOS' you don't delete a character, and there may be a checksum/length control or such in the hidden code executed after actual database read. Check also edfinition of ZTBC_CDPOS, as it must match this of former CDPOS (did some data element changed ?)

Else if you have kept a legacy system, you can do it like SAP do during upgrade, create transparent table like CDPOS, copy data from cluster to this transparent table and then transport this transparent table data to target, and there copy back records to cluster table. (Remember the problem that SAP get when, trying to convert BSEG into an optional transparent table some times ago)

Regards,

Raymond

[Former Member]

Hi,

No, the z-version and the CDPOS are identical, except for the Pool/cluster reference - that is the Z*CDCLS.

You may be on to something with the checksum. Any idea how to check those values before updating?

This is the code I used to update a few records:

PARAMETERS:

            p_matnr  TYPE matnr  DEFAULT '15000310' ," OBLIGATORY,

            p_batch  TYPE charg_d DEFAULT '106126'," OBLIGATORY,

            p_plant  TYPE werks_d NO-DISPLAY.

x_objid-matnr = p_matnr.

x_objid-werks = p_plant.

x_objid-charg = p_batch.

l_obj = x_objid.

SELECT * FROM ztbc_cdcls INTO TABLE lt_cdcls

                         WHERE objectclas = 'CHARGE'

                         AND   objectid = l_obj.

LOOP AT lt_cdcls ASSIGNING <cdcls>.

  l_start = <cdcls>-vardata+6(3784).

* l_start is everything from CDPOS to the end of VARDATA

* Insert the ZTBC_ prefix:

<cdcls>-vardata+6(2) = '005A'.       "Z

  <cdcls>-vardata+8(2) = '0054'.       "T

  <cdcls>-vardata+10(2) = '0042'.      "B

  <cdcls>-vardata+12(2) = '0043'.      "C

  <cdcls>-vardata+14(2) = '005F'.      "_

* Add the l_start after the '_' in ZTBC_

  <cdcls>-vardata+16(3784) = l_start.

**************

Is the above line changing the checksum?

**************

ENDLOOP.

UPDATE ztbc_cdcls FROM TABLE lt_cdcls.

[Former Member]

Hi Raymond,

I marked that as correct answer as it looks like it should work. Couldn't get it to work though. Looks like the people at source are willing to create a zCDPOS transparent table and copy the data into that. I'll take it from there.

Thanks for your help. I'd like to know why it didn't work but don't really have the time to do it now.

Slán.

[RaymondGiuseppi]

Would be much easier in source system.  Maybe "ZTBC_CDPOS" is too long, as there are only 5 spaces after "CDPOS" maybe a shorter name would have performed good, or you could have tried without shifting later bytes.

Regards,

Raymond

[Former Member]

thanks Raymond.

It's been copied to a transparent table so all is good now.

Those cluster pools are like a dark magic - tried to debug to see how SAP does it but got nowhere.

Thanks for your help.