When working with hexadecimal values, attribute bytes, "hidden" or "imbedded" decimal data, *LOVAL or *HIVAL you should be aware of the following:
- Literal hexadecimal values (i.e. X'..') are not supported anywhere in Visual LANSA, in any form.
- Applications that imbed IBM i attribute bytes in data will produce unpredictable results under Visual LANSA.
- The use of special values *LOVAL (i.e. hexadecimal 00 (under IBM i) and hexadecimal 01 (other platforms)) or *HIVAL (i.e. hexadecimal FF on all platforms) in any data (in any form) is not recommended. Note that under IBM i *LOVAL is interpreted as X'00', whereas on all other platforms it is interpreted as X'01'. In both cases the hexadecimal value represents the lowest possible value that can be sensibly placed into an alphanumeric field. Generally *LOVAL and *HIVAL will function normally. However, failing to observe these guidelines may produce unpredictable results:
- Avoid using them in new applications.
- Do not place fields containing them into database tables.
- Do not place fields containing them into reports.
- Do not place fields containing them onto screen panels.
- Do not use them in fields exchanged or passed between differing platforms (e.g. CALL_SERVER_FUNCTION).
- Do not use them as values used to access data in a DBMS
- The "hiding" of decimal data (packed or signed) inside alphanumeric fields is not a recommended technique. The Field Attribute *SBIN removes some restrictions and is described in the next point. Where this technique is used with message substitution variables unpredictable results will occur. Where this technique is used with database fields (e.g. an alphanumeric field of length 48 is actually a storage area for 12 packed decimal (7,0) numbers) predictable results will always occur:
- If the data is created on the current platform
- If the data always stays on the current platform.
- If the DBMS system you are using supports the storage of imbedded X'00' values in character or variable character fields (many do not support this). In other words, hiding decimal data inside alphanumeric fields may work as expected until some sort of data transfer, data storage, client/server, query or reporting application is used. At this stage, the whole "hiding" approach will totally collapse and the data will effectively become rubbish. If you have an application that makes heavy use of numeric data hidden inside alphanumeric fields then use the attribute *SBIN as described in the next point.
- The input and output Field attribute *SBIN can be used on an alphanumeric field to indicate that the database must not perform any character conversions on it. It only makes a difference on non-IBM i platforms as the IBM i database does not perform any character conversion on alphanumeric fields. On non-IBM i databases, when the client's code page is different to the server's code page, the database will need to convert between the two code pages. This conversion is usually not bi-directional for all characters in the character set. That is, a character entered as ¥ may be returned as Ñ. This is most commonly encountered with non-English and non-Japanese SQL Anywhere databases when a Translator is used in the ODBC data source. Refer to the Sybase SQL Anywhere Manual for more information on the use of a Translator. Do not change this option to attempt to make your embedded packed fields work as other more significant problems will be introduced. The issue can also occur with, say, an SQL Server database running on an English Windows server and clients running on Greek Windows. Using the *SBIN attribute on either input, output or both, causes the field to be created as a column of type binary in the database or the equivalent, for example, RAW in Oracle. All database reads and writes will just copy the actual data and not presume anything about the content. For example, embedded X'00' characters would be faithfully written and read from the database without causing any following data to be truncated. It is important to remember that this functionality is only true at the database level. Manipulating an alphanumeric field with embedded packed fields as an alphanumeric field, rather than its packed constituent parts, will still yield unpredictable results as described in the previous point. In RDML you must refer to the embedded fields and not the alphanumeric field. This is an example of the code:
FUNCTION OPTIONS(*DIRECT);
DEFINE FIELD(#A04) TYPE(*CHAR) LENGTH(4);
DEFINE FIELD(#A04A) TYPE(*CHAR) LENGTH(4) DECIMALS(0) TO_OVERLAY(#P07);
DEFINE FIELD(#P03R) TYPE(*DEC) LENGTH(003) DECIMALS(0) EDIT_CODE(J) TO_OVERLAY(#A02);
DEFINE FIELD(#C) TYPE(*DEC) LENGTH(007) DECIMALS(0);
DEF_LIST NAME(#L10) FIELDS(#P07 #P03R);
********** COMMENT(Insert 0 to 999 fields);
BEGIN_LOOP USING(#C) TO(1000);
CHANGE FIELD(#P07) TO('(#C - 1)');
CHANGE FIELD(#P03R) TO(#P07);
INSERT FIELDS(#P07 #A02) TO_FILE(F10);
END_LOOP;
********** COMMENT(Retrieve and converts previously saved fields);
SELECT FIELDS(#P07 #A02) FROM_FILE(F10);
ADD_ENTRY TO_LIST(#L10);
ENDSELECT;
**********
DISPLAY BROWSELIST(#L10);
- P07 is defined in the repository as packed, length 7 and decimals 0. A02 is defined as alphanumeric of length 2. These two fields are in file F10.
- Note that A02 is not manipulated directly in the RDML. Rather, P03R is manipulated in the RDML and A02 is only referred to in database commands like INSERT and SELECT. If, for example, A02 was used in a CHANGE command the behavior is unspecified.
CHANGE FIELD(#P03R) TO(#P07);
CHANGE FIELD(#A04) TO(#A02)
It may or may not work as expected depending on whether the Packed Field representation #P03R (i.e., #A02) contains a byte of 0x00.
- Using the Field in a File's Key
- Using the Field in a View's Key
- Using the Field in an Access Route's Key
- Using the Field in a Batch Control Key
- Using the Field in a Rule or Trigger|
- These uses are not enforced by the Repository. They may work on some databases and not on others. Because of this different database behavior it is advisable not to use binary fields in this way.