Special characters causing extract to split

[Former Member]

Hi,

We are having some problems with characters that SAP is not able to interpret. We have customer addresses entered through web. This sometimes contain special caharcters that SAP is not able to interpret/diaplay/print. SAP shows this as a '#' sign. We have another program that creates an extract of this data. Some of these "#''s are causing the lines to be splait in the extract and appear at the end after the trailer. Have anyone had this kind of an issue.Is there any solution?

Regards,

[Former Member]

Is it not possible for you to prevent the website users from entering these special characters OR intercepting the spec chars as they are loading into SAP?

[Former Member]

John is correct. It will be very difficult to make the extract right because of the special characters. You have to make it right at the source. You can have a mass clean-up for the existing addresses using a BAPI.

Unless you know what those special characters are, it will be difficult to search for them in your address and remove them. It is easier to simply overwrite them with the correct address. Have your frontend program modified so that it wont happen again, while you can do a onetime cleanup in the backend.

Regards,

Srinivas

[Former Member]

Hi All,

Thanks for the replies. But we have a lot of data coming in from web and from different countries. If i use a "MOVE" statement does SAP convert these to the equivalent character representation, '#' maybe, so that the lines does not get split to the end of the file?

Regards,

Hari.

[Former Member]

HI Hari,

Actually the #s you see in SAP may not be #s at all.

Anything that cannot be displayed in SAP will be displated as #s.You need to check for their hexadecimal codes before you make a judgement of whether to retain them or not.

Regards,

Ravi

[Former Member]

Hi Ravi,

Yes, we know that it is somethine else.But all i need to do is to replace this with a space or '#' when i move to the extract file so that it is not split. Will a "move' or "write" do this? i.e. convert to the character value .

Thanks ,

Hari.

[Former Member]

Hi Hari,

I'm afraid, a simple move or write will not do this.

If we know what character it is, then we need to use the replace or translate command .

Ravi.

[RichHeilman]

I'm wondering if you search on that '#' sign if you will get a positive indicator. What I mean is in your extract before you do the split. Try searching for the "#" and replacing them with space. If the pound is the representation of the value underneath, the I don't think that this will work, if it is converted to the "#', then it might.

translate iextract-rec using '# '.

Regards,

Rich Heilman

[Former Member]

Sorry Hari, you will not be able to do that. As I said it is very difficult to work with those characters without knowing how many and which character set. You said, the addresses are from different countries, does that mean different languages as well? Are you checking for the language when you are extracting?

A 'MOVE' or a 'WRITE' will not help.

Srinivas

[RichHeilman]

I think you may have to test each character of the entire string. Maybe split the fields into a column of an internal table, loop thru that internal table, and test for a hex value, if so, the replace that value, then rebuild your string using the internal table.

Regards,

RIch Heilman

[Former Member]

We had this issue in a previous implementation, luckily we were able to identify the characters, it was a combination of clean up of data on the 3rd party side & we also had to use code to replace the special characters with spaces.

See if the Function Module SF_SPECIALCHAR_DELETE helps you..

[Former Member]

Hi All,

Thanks a ton for the responses. I guess the issue is as follows, but not sure what would be the best approach to correct it.

. The “unreadable” character that causes the split is the CR(Carriage return) that has a hexa decimal code ‘0D’( I checked the data before correction in PRD, from the change records, the two ‘#’’s have the hexa code 0D0A. We determined the exact character by looking at the "changes" for that customer in debug mode. I looked at the hex value of

the deleted characters in debug and found that it was '0D0A', where as ou are aware '0D' is the code for CR(carriage return). Unfortunately we

do not know the exact keys that should be used to reacreate the same. This is caused as DOS/Windows based systems use CRLF(Carriage return /Line feed) for a “new line” while UNIX uses only LF. Some times the compiler fails to interpret this new line symbol coming down from DOS/Windows based systems and causes the corruption of the file.

Possible Solutions:

Check for ‘#’ in the fields and if it has an ASCII(Hexa) code of ‘0D’ replace by a space?

Is there a better method?

Regards,

Hari.

[Former Member]

Try this code.

DATA: v_hash(4) TYPE x VALUE '0D0A',
      v_string(100) TYPE c.

REPLACE v_hash WITH space INTO v_string.

Srinivas

[Former Member]

Hi

Try using FM SSM_REPLACE_CHAR_BY_HEX_VALUE. Pass the problematic string to the FM , return value will converted output.

Regards

Kalpana