Re: Varchar/Char Compatibility

rridley@sin-pss.dhl.com (Richard Ridley's Account) writes: >Dear All, >We have found that changing some columns in our databases from char >to varchar can save up to 40% of our disk space. >Now I know about the update performance overhead, and this will not >be a problem for us, since our database uses mainly inserts and >deletes. >In the 'Guide to SQL: Tutorial Version 4.1' page 10-26, it says: >"Furthermore, VARCHAR data is immediately compatible with most >existing programs, forms, and reports. (Forms must be recompiled. >Forms and reports should, of course, be tested on a sample >database.)" >This is rather confusing to me, and I was wondering if anyone has >tried this in the past and had any problems, or if anyone knows the >reason for having to recompile forms (If, indeed, this is necessary). I don't think you have to recompile forms to use them, but certain display anomalies may occur if you don't. Using VARCHARs in forms and reports can be tricky, because of the NULL terminator in VARCHARs which doesn't occur in CHAR data types. This affects things like CLIPPED and PRINT statements where you might want the full n characters of a VARCHAR to print so that columns line up correctly. I've seen this happen in forms as well (anything to the right of the line displaying a VARCHAR looks shifted over). My personal rule of thumb is that, for VARCHAR columns, define them as FORMONLY TYPE CHAR in the ATTRIBUTES of the perform screen and as CHAR(n) in the 4GL code, rather than using VARCHAR or LIKE syntax. A pain, I admit, but better than other alternatives I have thought of. ================ Dennis J. Pimple Informix CSE / Denver 303-850-0210