Removing Whitespace Pad from JDE String

szNick

Member
I'm aware that the JDE String type always pads whitespace characters on a String. I've got a requirement from a web integration to remove whitespace characters from the table column for ALKY - Long Address Number, a JDE String. Is there a way to remove the padding from a JDE String in a JDE table or am I stuck with it? Looking for a way to avoid having the web integration have to perform the task on every table row. The String is typically 9 characters long, but not always, so a custom data type with a length of 9 isn't a solution.

This is a task I need to replicate on 3 of our systems: XE 7.33, 8.98, and 9.2.

Any advice or experience welcome. Thanks.
 
Hi,

Not a good idea to change the standard DD item. Couple of ways to do so
1. One way is to create a custom DD item to match your requirement.
2. Other way is to create staging table(s), replicate the data from JDE to staging tables using scripts, remove padding for that column in staging tables, use the final table as source to web integration.
3. Other way is if web interface supports any customization, remove the whitespace padding at web interface and use for integrations.

Thanks
 
I thought this was database related, rather than JDE specifically. At any rate, you won't be able to change it really.

For an integration, it would be fairly normal for that process to trim strings as needed, or you could create a SQL view with a trimmed ALKY in it.
 
Is this a custom table?

What about changing the way the data is loaded? Use a integer variable with the JDE code converting the ALKY (string) to a numeric (use JDE code to convert to new variable using conversion ER business function). If not custom table add a new field at the end of table to store the 'converted' value of the ALKY to save the field being use for web integration.

* Yeah, would not recommend changing the DD value...could cause HUGE problems.
 
What is the integration? What language is it written in? I 100 percent agree with Mike, changing the DD is not a great solution.
 
Thank you everyone for your input. We ended up going with a web integration for this issue, because adjusting the DD would have been extremely risky and anything else would be wholly inefficient for the volume of rows we expected. Thank you for responding, this was a good lesson to learn.
 
Back
Top