Question How To Avoid Non-printable Chars During Write-xml

[philippoommen1]

Hi,

Please help us by suugesting a simple way to FILTER the non-printable characters ( CHR(0) to CHR(31) ) in the output XML file , which is generated from WRITE-XML function of Progress.
Can we customize this function ? Means, if a field value contains CHR(0) to CHR(31) then replace with blank.
TIA
-Philip-

 

[KrisM]

There probably are better solutions, but you could output the write-xml to a longchar variable and do the substitutions on the longchar before you write it to the actual file ?

 

[TomBascom]

I doubt that you really want to do that.

This sounds like an over-reaction to what is probably a simple misunderstanding of something.

What is your actual problem?

 

[TheMadDBA]

To me the question is why do you have those non printable characters in your database? If they are garbage then they need to be cleaned up. If they serve some kind of purpose like storing delimited values then they need to be handled differently (and then slap some developers around for doing it).

 

[philippoommen1]

Sorry I missed to explain why we need that.

Users copying contents from web pages and directly paste the content to our progress application. Progress accepting it however when we display that data in Crystal report (Crystal report used XML as data source from Progress DB) it crashes.

We are comfortable with Progress and if we can eliminate those special characters from Progress side it would be great.

-Philip-

 

[philippoommen1]

Contents from the web page contains this special characters FYI

 

[TheMadDBA]

First... Use REPLACE to get rid of the values from the editor or fill in before saving to the database.

Then use REPLACE to get rid of the values that already exist in the database.

 

[philippoommen1]

Time being it is practically not possible with our application because we around 100 active reports . Tackling special chars at entry level is not possible now.

 

[TheMadDBA]

Then you will either have to use the solution suggested by KrisM or some variation of that (replacing the CHR values in the temp-table/dataset before the WRITE-XML).

And you will have to do that in every program that exports the data.

 

[TomBascom]

You can do it right... or you can do it twice (or, more likely, forever).

 

[TomBascom]

Also -- getting rid of everything from 0 through 31 is almost certainly a bad idea. That would, for instance, include TAB, NEWLINE & CARRIAGE-RETURN.

You really ought to look harder at what the problem characters actually are and figure out exactly why Crystal doesn't like them. You might be (very) surprised at what you find.

 

[RealHeavyDude]

Users will always copy selected texts from web pages and/or MS office documenets and paste it directly into ABL widgets. There is nothing you can do to prevent users doing that. You could try to enforce some policy on them that requires them to use something like notepad as an intermediate - it won't work.

Therefore, you need to build a defense into your application. If your application utilizes some form of data access layer or capsuled functionality to perform the CRUD operations in your application than that it will be rather easy. For classic client/server applications that mix and match UI and business logic it might be more challenging.

Nevertheless, I don't think one can blame the users. It is this cool IT that we have blessed them with - therefore we need to take care about it for the user. Why should users care about something they can't even see?


Heavy Regards, RealHeavyDude.