Curiouser and curiouser…

Our attempt to use ICONV/OCONVs as the descriptions for relational keys is actually almost working. What happens now:

1) When that field does not already have a value, a search term entered at a relational field will find the correct values and display the correct descriptive string. When the record is saved, the correct _key_ is saved in the correct field.

2) If a relational field is nulled out, a null is correctly saved in the appropriate position in the record.

...BUT...

3) If a relational field is changed from one valid entry to another, everything appears to work, until the record is saved, whereupon the field reverts back to its prior value. This reversion happens during the system WRITE event, and we seem to have no control over it.

A few details…

i) We have a single routine doing both validation and conversion. It jumps through alot of hoops (including setting and retrieving "@properties") but generally does its job quite nicely.

ii) Since validations are not called for null entries, we've implemented a CHANGED event handler to deal with them.

iii) We've managed to detect whether our validation is being called from within the WRITE event or not, and behave differently if it is.

iv) The keys in question are not generally printable characters; they're 'compressed' to save memory. Does the recent discussion of leading zeroes and numeric value changes bear on our situation?

View this thread on the forum...