Re: Checking datatype of CHAR variable in 4GL

In article <6ch9gn$p5q$1@news.xmission.com>, Marco Greco <marcog@linux.ctonline.it> wrote: >Well, my assertion of incorrectness springs from essentially two facts: > >- change in behaviour across versions: WHENEVER ANY ERROR CONTINUE did *not* log > conversion errors up to and including (I think) 4.12/6.00. Right, largely because conversion error handling in general was (IMHO) broken and inconsistent in the first place. This brings us back to the days where RDS did one thing and compiled 4GL did another. The concept of uniform Error Scope (and the "AnyError" vs "Normal" terminology I invented to distinguish traditional c4gl methodology from the better, more thorough RDS methodology) came in with 4.12/6.00. This cleanup helped 4GL programmers take better advantage of considerable internal cleanups that Jonathan performed for 4.12. (See $INFORMIXDIR/release/TOOLREL_4.1 under "CHANGES TO 4GL ERROR HANDLING" for the release note I wrote on the topic... it was later folded into the 4.1 and 6.0 4GL Supplement manuals, 1996 editions). Honestly: did anybody out there PREFER the OLD way to the post-4.12 way? Recall what that really meant for conversion errors: at the time of the error, the conversion error message was just dumped to stdout/stderr with no context whatsoever! >- inconsistency with sql error trapping behaviour: a comparable example would be > to prompt the user for a quick sql statement, and PREPARE it with WHENEVER > ERROR CONTINUE in effect. in case of error, you are presented with a negative > status & SQLCA.SQLCODE, and nothing in the error log. I'll agree that this should be programmer-selectable... but the behavior is as documented under the startlog() function documentation. >In due time I went through the release notes, and I must say I agree on the fact >that back in the old days conversion error log trapping was confusing for the >user, however I'm not sure the changes introduced go in the right direction: >nowhere in the release notes it is said that the intention was to change the >error logging behaviour described in the 4gl ref man, vol 1, chapter 2 (when >WHENEVER ERROR CONTINUE is in effect, no error is written to the error log), >plus logging conversion errors without specifing their exact location, and >without warning the user, now means that I can no longer track down conversion >errors - at least in the good old days the user would come to me and say "the >computer said this when I was doing that"! To the best of my recollection, conversion errors were never given context information in the prior releases either... >The sad note, however is that this is not the only minor behavioural change >across minor release numbers: for instance PAGE HEADER #1 processing (as opposed >to FIRST PAGE HEADER) broke some havoc, over here. Not sure what you mean here... Ace and 4GL reports control-break logic were badly broken in the old days; it took me four years of heavy lobbying to get Product Mgmt at the time to agree. (It used to be that the report writers would trigger a new page as soon as the existing page was filled, rather than waiting until the next page was actually necessary. This had UGLY side-effects, including erroneous group info if you printed group-specific data in a PAGE HEADER). -- Alan Denney yosemite_at_netcom.com "San Francisco politics are interesting in the sense that zoo animals are interesting." -- Duane Garrett (1946-1995)