Re: VIEWS compared to Nodes as Windows into data

"Laconic2" <laconic2_at_comcast.net> wrote in message news:CpqdndIAYv-GLhPdRVn-gw_at_comcast.com...
> > This one always sounds like COBOL and card-columns to me - how often is
it
> > really, really a limit on a value that it be restricted in number of
> > columns, unless this is a for-computer-purposes "code field" of some
sort?
> > Ah well -- some folks like more restrictions rather than fewer and this
> > certainly helps clamp down on those users insisting on putting entire
> values
> > into their forms.
>
> It depends. Sometimes it's worthwhile to have specific column limits on
> data for purposes that are quite legitimate.
>
> For example, I've seen address mailing systems, (including BANNER),
where
> the limits on various fields that make up an address are very carefully
> built so that the entire address will fit on a single address label. That
> may seem like a trivial issue to you... unless you've ever dealt with a
> situation where the addresses can't be printed on a label.

I've spent enough time with names and addresses to know they are not at all trivial and, yes, number of characters fitting on a single label is very important. This was more clearly an issue of counting characters with fixed size fonts, but remains in our systems none-the-less

>
> > I'm using the same def as you -- the end-users of the database are both
> > application software developers and their users. But, with PICK, the
> > end-users could easily be non-IT professionals since the language is
> really
> > very easy to use.
>
> Well, in a former lifetime, we could let the data analysts and
programmers
> use SQL, while
> the end users used Datatrieve. (I know, I know, you don't like
Datatrieve.
> Whatever!)

Datatrieve was fine for what it was and that was not a powerful multiuser database system and if the alternative was SQL, then I agree with your assessment to have users in Datatrieve. smiles. --dawn Received on Wed Apr 28 2004 - 04:17:50 CEST