Application Development Discussions
Join the discussions or start your own on all things application development, including tools and APIs, programming models, and keeping your skills sharp.
cancel
Showing results for 
Search instead for 
Did you mean: 

appending '#' in text file while uploading through CG3z

Former Member
0 Kudos

Hi ,

I created a text file with following parameters

filename: abc
Save as type : Text documents
Encoding : UTF-8

I tried  to upload the abc text file from my PC  to a path in  AL11 tcode  through CG3Z tcode . It got uploaded,but

all lines in the text file ended with '#' which i do not want.Kindly help to avoid '#' character after end of the line.

data is as follows after uploading text file in application server.

2|01.01.2013|31.01.2013|Remarks|jp|||#

2|01.01.2013|31.01.2013|Remarks|jp|||#

2|01.01.2013|31.01.2013|Remarks|jp|||#

2|01.01.2013|31.01.2013|Remarks|jp|||#

1 ACCEPTED SOLUTION

rdiger_plantiko2
Active Contributor
0 Kudos

Jayaprakash, when uploading a text file with CG3Z, use text mode (ASC), not binary mode. The special sign is x0D. When transferred binary, the Windows newline bytes (x0D0A) will be transported as-is on the server. In a Unix system, the newline character is just '0A'. The '0D' remains as orphan. It will be displayed with the replacement character '#' in the debugger (and elsewhere). Regards, Rüdiger

6 REPLIES 6

Former Member
0 Kudos

Hi Jayaprakash,

     Usually un-converted characters appear as '#' in AL11. It means that proper code page conversion hasn't taken place when open the data in AL11.

     In your case, it maybe that the line feed character is not getting converted thereby appearing as '#' in AL11. Check if this is only a data appearance issue or it is affecting any of the processes where the file is used.

Hope this helps.

~Athreya

rdiger_plantiko2
Active Contributor
0 Kudos

Jayaprakash, when uploading a text file with CG3Z, use text mode (ASC), not binary mode. The special sign is x0D. When transferred binary, the Windows newline bytes (x0D0A) will be transported as-is on the server. In a Unix system, the newline character is just '0A'. The '0D' remains as orphan. It will be displayed with the replacement character '#' in the debugger (and elsewhere). Regards, Rüdiger

Former Member
0 Kudos

Hi Jayaprakash ,

Please go through the below thread link ....

http://scn.sap.com/thread/3300009

Hope this will help u .....

Regards,

AKS

Former Member
0 Kudos

Thanks for your reply.Our system is UNIX Unicode system .I have to upload UTF-8 encryption code text fie as it contains chinese characters.But,It is giving dump "CONVT_CODEPAGE" when i upload text file of encoding type UTF-8  and transfer format is ASC . kinldy help  me.

Former Member
0 Kudos

Thanks for your reply.Our system is UNIX Unicode system .I have to upload UTF-8 encryption code text fie as it contains chinese characters.But,It is giving dump "CONVT_CODEPAGE" when i upload text file of encoding type UTF-8  and transfer format is ASC . kinldy help  me.

0 Kudos

Jayaprakash,

I just tested uploading an UTF8 file with CG3Z in 'ASC' mode, containing three German 'Umlaute' (ä, ö, ü). The SAP system is Unicode (i.e. UTF-16LE, SAP's standard Unicode encoding) on a Linux computer.

Result:

  1. When the file contained the so-called 'BOM' at the beginning, the upload failed (the result file was corrupt). The BOM is the 3-byte-sequence EFBBBF at the beginning of the file, used by some programs as indicator that the subsequent file content is UTF-8 encoded.
  2. An UTF-8 file without this BOM could be uploaded as expected on the server.

Maybe you check whether the first three bytes of your file on the PC are EFBBBF. If so, try to remove these three bytes with a Hex Editor, and try the upload with CG3Z again, for the file without BOM.

Regards,

Rüdiger