On 19 Oct 2001, at 11:48, Woody wrote:

> From: <lester@...>
> > I have just been dumped with a load of Mucrosoft Developer
> > Network stuff including the XP releases, and on looking
> > through the notes, I found some interesting comments on the
> > 'SQL Standards' for table and field names.
> >
> > Mucrosoft seem to be suggesting that using [] around table
> > and field names is the correct way of hadling names with
> > spaces.
> >
> > Is this just another 'Mucrosoft Standard' or have I missed
> > something on the standards front?
>
> Calling them Mucrosoft is a clear indication that no matter what they
> say or do, you won't be satisfied. However, that's not the point and I
> don't want to start yet another MS discussion.
>
> MS Access has used the square brackets for as long as I can remember
> to enclose field names. The SQL-92 standard is using quotes, but I
> think it is fair to point out that using quotes means "take this name
> literally, including case sensitivity" whereas using brackets just
> means take the name in it's entirety. Ask anyone who has inadvertently
> used quotations to create field and table names and then tried to
> access them without using the quotes. How many posts have you seen
> about this? I've seen quite a few of them.
>
> Myself, I have no preference and could live with either one.
> Personally, I don't think spaces should be allowed in table and field
> names but other characters would be good such as hash marks, etc. to
> denote special fields. Since I left C a long time ago, case sensitive
> names don't appeal to me anymore so I think that quotes around a field
> name should only signify the name may have special characters, not
> that I want case sensitivity. Maybe I'm alone in that, but I've been
> there before too. :)
>

I tend to stick to all upper case, splitting words with an underscore,
because I know that that format is universally supported across all
engines. Most engines should support other name formats in
quotes, the standard says they should -- so most probably do.
Square brackets might not be universally supported.

There is also another reason why I stick to the uppercase split with
underscore format, and that is that if I know of a field as
CUSTOMER_ID, then it is CUSTOMER_ID everywhere it gets
used, and it's always in that format. Being consistant throughout
your applications, has the advantage in that 5 years from now, you
know what format was used, without having to even look at the
source code or table definitions.

Paul

Paul Schmidt
Tricat Technologies
paul@...
www.tricattechnologies.com