Re: D3 ODBC Problem

Hi
I must be weird. I actually think that a program with more than one INPUT and associated edit routine is seriously weird. Sorry I should say two as I have a separate routine for my control line (Save, Exit, Change Field) to my field data entry routine. In NEAT3 I only had one but moved to two when I switched to Reality and VTE6 screens in 1977.

I do remember one British expert going a little slack-jawed when I showed him a screen with 42 fields (as requested by the user) and happily hopped about changing fields at random. He did ask if I realised that the accepted wisdom was to start the entire screen again and prompt for each field in turn. I think I looked a little bemused and asked if he hadn't heard of event driven programming (this would have been around 1979-80).

Ahah! That phrase "accepted wisdom" reminds me of another party deriding complex keys and saying did I not realise that the accepted wisdom was to use random numeric keys for all Pick data. Of course I was not impressed and wondered why one would do such a thing. Now I realise that this was the "accepted" way of getting around the foolish concept of case sensitivity so that one did not wind up with stock items of "nails" and "Nails" and "NAILS". My approach to case-sensitivity is to ban it for any key. I simply set alpha keys to being Upper case on entry and yes I always validate that it is A-Z and if I ever have to use Cyrillic I am sure I can do a similar trick there. We did some work recently on a banking system that did not have decent standard edit facilities so the first thing I did before we cut a line of operational code was to write an edit routine that we used at all times. I do remember, with some amusement, a tester sitting with her finger on the keyboard saying with a smile "I'll break this yet". She didn't break it but she did get an awful lot of bells back.

As for external sources, I actually have a wide variety of sources and I assume that all are suspect. My standard approach is to set up a standard interface to the master system say for card purchases through tills or card acceptors and then pass each suppliers info through a conversion program that validates every attribute. Errors in the data passed down are frequent from some suppliers and they are definitely rejected before they hit my database. This makes it extremely simple to incorporate a new supplier such as happens with business take-overs.

Also the approach makes changes, debugging and training much simpler as every screen is identical in operation. In fact only last week I had an issue that took ten minutes to fix. A bank in its wisdom decided to change a six numeric key to six numeric with leading zeroes. I regard leading zeroes on numbers as even more stupid than case sensitivity and edit them out, anyone who has seen the chaos caused by false emergency calls in Australia would understand - the emergency number is triple zero and the area codes start with zero, so what happens is people in an office dial zero to get a line, followed by another zero for the area code, glance at the number to double check and promptly enter another zero. Sounds OK but many new office systems do not need a zero to get a line so up pops emergency. In my programming approach I simply changed my global dictionary for the bank number to alpha numeric and added a string check of (6N) to it. Problem solved, edit all OK and error message OK as well.
Peter McMurray


"Tony Gravagno" <address.is.in.posts@xxxxxxxxxxxxxxxxxxxxxx> wrote in message news:nv8q84h40sl7du8b0gvd9hjqbrq0kdbncj@xxxxxxxxxx
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

.

Relevant Pages

  • Re: local area connections
    ... Don't edit the reg. ... Type the following commands at a command prompt ... > in the registry i found referrences to the previous> numbers but there were also four other keys in the same> dir that the referrences to the numbers were in. ... >>shows up under network adapters. ...
    (microsoft.public.windowsxp.network_web)
  • RE: Explorer "Edit File Type" dialog Edit/Remove buttons grayed out
    ... Some additional discoveries since first post... ... The following Registry Key sets are probably involved somehow: ... made in on set of keys is automatically changed in the other set. ... So I couldn't edit it or even ...
    (microsoft.public.windowsxp.general)
  • conditional editing permissions for table
    ... In your database table put a timestamp of when the user, ... entered then set it to zero. ... zero then you can't edit it. ... add to as things happen in the business. ...
    (microsoft.public.sqlserver.security)
  • Re: OpenSSH on win2k
    ... create the sys env var ALTCMD, set it to %ComSpec% (edit ... create the sys env var HOME and set it to D:\Var\SSH ... create the dir .ssh in D:\Var\SSH and copy the appropriate pub keys ...
    (comp.security.ssh)
  • Re: On writing negative zero - with or without sign
    ... There is no sign that J3 has considered the request. ... that printed +0.0 for negative zero, and I believe 0.0 for positive ... In an earlier posting, I proposed adding three new edit descriptors, ... The edit descriptor ZU together with the edit ...
    (comp.lang.fortran)