I'm just curious if anyone can shed some like on this odd behaviour I'm seeing with the ASCII null character (128) in a UV string variable. We have bidirectional sync between UV and MS SQL 2005 over ODBC, and it's possible to get the null character back from the SQL side. It doesn't happen under normal circumstances, but is within the realm of possibility. I guard against it with:
CONVERT CHAR(128) TO '' IN VARNAME This worked fine when originally implemented (UV 9.5.1 I think), but now it seems to be broken (UV 10.2.7 on RH EL 5.1). We're testing an upgrade of our CRM software on the SQL side, and a developer was testing trigger changes that caused some fields to be sent to UV as null instead of empty strings. This caused a program which tries to build a file ID from one of these variables to abort on the READ statement. I put in some print statements for debugging, and I'm getting very odd results. Here's the code: 0089: CONVERT CHAR(128) TO '' IN STATE 0090: STATE = UPCASE(STATE) 0091: PRINT 'STATE = "':STATE:'"' 0092: PRINT 'LEN(STATE) = ':LEN(STATE) 0093: PRINT 'SEQ(STATE[1,1]) = ':SEQ(STATE[1,1]) 0094: IF STATE = '' THEN 0095: PRINT 'UV THINKS STATE IS AN EMPTY STRING' 0096: END ELSE 0097: PRINT 'UV DOES NOT THINK STATE IS AN EMPTY STRING' 0098: END 0099: READV DUM FROM FILE.CF, 'STA*':STATE, 1 ELSE and here's the output it produces: STATE = "" LEN(STATE) = 0 SEQ(STATE[1,1]) = UV DOES NOT THINK STATE IS AN EMPTY STRING Program "PGMCR1001": Line 99, Improper data type. I can eliminate the error with the following code: STATE2 = '' FOR I = 1 TO LEN(STATE) STATE2 := STATE[I,1] NEXT I STATE = STATE2 Is this a bug? It looks that way to me. -John _______________________________________________ U2-Users mailing list [email protected] http://listserver.u2ug.org/mailman/listinfo/u2-users
