Re: users pasting hex '41' into char fields...

On 06-Jul-2016 09:54 -0500, Gerald Magnuson wrote:

On 05-Jul-2016 16:49 -0500, CRPence wrote:

On 05-Jul-2016 15:14 -0500, Gerald Magnuson wrote:

[…]
we are getting a hex x'41' at the end of some of the character
strings users are pasting into green screen fields..

So that pasted data. had been copied from where, for example?

The implication is that the IBM i program is receiving, as EBCDIC
SBCS alphanumeric character data, the code-point 0x41, as a
single-byte /character/ value in a character string pasted into the
input\output field? And always\only at the end of the strings?

[…]
I do feel that this data is mostly being copied from Outlook, I have
found instances of notes having the x41 bytes in the middle of a note
string.

The Required SPace (RSP) is visually indistinguishable from a blank\space character; each is a glyph with no visibility in contrast to the background. There is often little value in replacing a valid 0x41 with the 0x40, except for when the data must be searched\compared, and the algorithm\method does not easily enable a choice of whether the two code-points must compare equal or must be treated as unequal.

currently this file is a legacy DDS file, but if I want to "reject"
this byte, as invalid data, as I am told our mySQL databases do, how
would I code my DDL?

The CHECK CONSTRAINT can enable that, though often considered less desirable to reject the data, than to accept-data-with-modification, either by the application [e.g. coding a translate of the data entered on the display] or via the database [e.g. with a TRIGGER upon INSERT into the file]. For example, as a constraint, perhaps one of:

using /native/ CL [Add Physical File Constraint (ADDPFCST)]:

ADDPFCST the_file (*CHKCST)
CST(cst_name_reject_0x41)
CHKCST('locate(the_field, x''41'')=0')

or via the SQL:

alter table the_file
add constraint cst_name_reject_0x41
check ( locate(the_column, x'41')=0 )