At 12:21 PM 10/2/2015, Lawrence Lustig wrote:
Client installed the latest 9.5 release and they're seeing strange
behavior, but
only in a single form.
This form contains variable assignments in the Variables list like
the following:
12 : TEXT fEQCO_TaxID = (CTaxID)
In this case, CTaxID is a TEXT(20) column in the underlying table
that is often
NULL. I would expect the variable fEQCO_TaxID to wind up set to NULL.
Instead, it's getting set to a 20-character long string where each
character is
the null byte (00000000). A comparison to NULL yields FALSE and
SLEN(.fEQCO_TaxID)
yields 20. As far as I understand, this string value should not be
able to exist
in R:Base.
This is happening to multiple TEXT variables set to NULL in the
form's variable
list but only for this one form. I built a quick test form against the same
column in the same table and the assignment works correctly. So,
it's only limited
to this one form (which is large and complex).
I'm sure that the actual value of CTaxID in the table is a correct
R:Base NULL
value. Also, the problem does not occur with SELECT . . . INTO . . .
Finally, I checked the form's EEP code for any instance in which SET
NULL is used
to affect the NULL setting, and there is no such instance.
Has anyone had any experience with getting odd null-char strings in
place of NULLs
in form variable assignments?
Since no one responded to your post, it is possible that this is an infrequent
problem. However, it just happened to one of our corporate customers who are
always on the cutting edge, and are always the first ones to deploy the latest
updates.
Technically, the issue at hand has to do with NULL terminating empty
values when
initializing new row (ENTER USING formname), and a form with
expression variable
set to a column.
The resilient R:Dream Team has already fixed this issue and provided
the updates,
upon request, to customers with Corporate VIP Status.
A public update with more goodies, as always, will be released soon.
Very Best R:egards,
Razzak
