Like everything else in the world, to much is like not enough. When writing
some piece of code, you must write it in a way that will convey the maximum
quantity of useful information to the programmer but without cluttering the
whole thing, because at this point the process will become
counter-productive: instead of diminishing the possibility for the
programmer of writing a bug, it will increase it.

« how long ago did people start using "i" for integer? "For i = " was one
of the first constructs I learned almost 30 years ago. »

For those interested, this old notation came from the first commercial
version of Fortran and had then a functional purpose: all variables
beginning with one of the letters i, j, k, l, m and n (taken from the
enumeration i .. n corresponding to the first two letters of the word
INteger) were automatically declared to be of type integer and all others
were dimensionned as float by default.

In fact, in Fortran 4, I'm not even sure if you could dimension a variable
beginning with one of the letters i .. n to *not* be an integer. (Since my
old manual of Fortran 4 is gone since a very long time, I can't no longer
verify this point.) In Fortran 5, you can easily declare one of these
variables to not be an integer but still, if you don't say otherwise, they
will be of type integer by default.

--
Sylvain Lafontaine, ing.
MVP - Technologies Virtual-PC
E-mail: http://cerbermail.com/?QugbLEWINF


"Robert Morley" wrote in message
...
I still don't buy that this is either product-specific or amateur-specific.
I've seen countless numbers of experienced, formally trained (and who
learned it on their own) database programmers on every platform I've ever
used who use "tbl" for tables, "vw" for views, "usp" for user stored
procedures, not to mention "frm" for forms, "rpt" for reports, etc., ad
nauseum.

Personally, I don't see the point of starting ALL objects in a category
with the same letters; that's generally redundant (though occasionally
useful when you're trying to distinguish between views and tables, etc.).
My general preference is to base it around the function of the object.
"acct" for account-related tables, "resp" for respondent-related tables,
"list" for simple lookup-type tables, etc. Only for objects that don't
have a significant inter-relationship with the rest of the database (i.e.,
localization tables, user preferences, etc.) do I use the generic "tbl",
"frm", or whatever.

And while "tbl" itself may have first appeared in a Smart Access article
in 1993, as I said, Hungarian notation itself pre-dates that. As I said,
Simonyi Károly (aka Charles Simonyi) did indeed work at Microsoft, but he
started Hungarian Notation back when he was working for Xerox. It's
hardly a surprise that it later appeared in a Microsoft product that he
worked on. Hell, ignore Hungarian notation for a moment, how long ago did
people start using "i" for integer? "For i = " was one of the first
constructs I learned almost 30 years ago.


Rob

"Craig Alexander Morrison" wrote in
message ...
Oh and just for the record, Hungarian Notation became popular with
languages like VB/VBA, but actually pre-dates it. The inventor, Simonyi
Károly, was working for Xerox at the time and only much later did he
move
to Microsoft.

For the record "tbl" and other such fripperies first appeared in a 1993
Smart Access article and has subsequently appeared in the ADH books. I
don't
mind one using tags in code but not for database objects. Charles Simonyi
actually worked on Access 1; I am not sure what he thinks of the
Lesynski/Reddick extensions.

It is a good sign of an amateur with limited experience of other
products.
Some amateurs are very good programmers though.

Nearly all formally trained Relational (or SQL) Database designers would
find this "tbl" tag laughable.

--
Slainte

Craig Alexander Morrison
Crawbridge Data (Scotland) Limited

"Robert Morley" wrote in message
...
Like I said, different ways of thinking. I look at most of your points
and disagree with them either in part or in whole, but frankly, this
isn't
the place to get into this kind of discussion. The original post has
been
answered with two different solutions, and that's the end of it as far
as
I'm concerned. I just bitched someone else out in another NG for
exactly
this kind of "mine is bigger than yours" discussion that serves no
purpose
but to bicker pointlessly. Everybody's got their favourite apps and the
apps they think are toys, we simply disagree on which ones are which.





Rob

"Tim Ferguson" wrote in message
...
"Robert Morley" wrote in
:

Obviously someone thought so, or they never would've designed combo
box lookups to work in tables.

There are several things in Access that relegate it into the "toy"
platform in the eyes of other database developers on "real" systems.
The
quaint but misguided fashion for putting "tbl" in front of object names
is one; the presence of the "look up field" is another. I regret this
because when you get up close, Jet is a pretty fine database engine and
Access is a flexible and usable rapid development platform, but it will
continue to get a rotten press as long as it's aimed at the Janet and
John level of user. The type of users, in effect, that get drowned in
any
case as soon as they step off the dumb-spreadsheet kind of appliction.

FWIW, it seems that the Access-as-toy party has won the debate because
Jet development is being taken over by the Access UI team. I think it's
time to be off to MySQL before they put in the paper clip telling you
not
to put financial data into an integer field.

What it really comes down to is that each of us has our own opinions
and ways of doing things. Don't get upset with someone just because
they think and work differently than you do.

I get upset because of two things. Firstly, posts like yours may be
seen
by people who know about databases but not much about Access, who will
merely have their suspicions confirmed that access is a plaything for
people who don't know their way round Codd or Date. The second reason
is
that they may be seen by people who don't know much about Access or
databases, and who will then think this is a good and reasonable way to
use it; and whose horizons will forever be shortened.

All the best


Tim F