Re: D3 ODBC Problem

Having seen a lot of code in a lot of different shops I can tell you
that data validation beyond what's required for specific context is
not the norm. Pick guys mostly code like this:

CRT @(x,y):"ID please":
INPUT ID
READ REC FROM FV,ID ELSE...
CRT @(x,z):"Info please:"
INPUT INFO
REC<Q> = INFO
WRITE REC ON FV,ID...

The people who have been doing this a while (the entirety of present
company, I'm sure) have subroutines (internal or external) for screen
output, user input, reads, and writes. Many people claim this is
their M.O. but have a look at code coming in from non-telnet sources
and everything breaks down. Examples include data input from FTP
transfers, data received from web services, data entered in browser
forms, data imported from CSV or other formats... Somehow there is the
assumption that if the means of acquisition is not an INPUT statement,
at least when it's not hooked to a user via telnet, that the data must
be good. The idea doesn't really occur to people that they should be
running all of this data through the same cleansing functions - since
the MV DBMS model doesn't do this natively, as DBMS administrators we
need to make sure the application provides the services. Some sites
do this with triggers. I dunno about other platforms but I prefer to
avoid triggers, particularly with D3.

Lest the grass look greener on the other side, one of the things
provided by the relational model is referential integrity enforced at
the DBMS level. While RDBMS guys use this to beat us over the head,
many of them also leave this as the last thing they do, right down
there with comments, error handling, and optimizations.

T
.