Naming Convention for Columns

Naming Convention for Columns

Post by Dave Mull » Fri, 06 Mar 1998 04:00:00



Hello all,

We are setting up new database naming conventions, and I'd like to
hear other people's thoughts on what they consider to be important
considerations.

In particular, I'd like to know how people feel about prefixing the
names of columns in a relational data base with a short prefix
representing the table to which the column belongs. (Foreign keys
would retain the prefix of the foreign table, i.e., the table being
referred to. This would also be true for denormalized, redundant data:
the redundant columns would carry the prefix of the "owner"/master
table.) The lead developer for this project is strongly in favor of
using such prefixes; they were used here in the past in the DBAM data
base being replaced. He likes not having to specify the name of the
table when he mentions the column in code, and also feels that the
prefix helps remind the developer/user of which table they're working
with.

I prefer not to use such prefixes. The reasons I have given are:

1) It's redundant. If a column exists on more than one table and the
reference is ambiguous, use "table.column". It also actually makes the
column name longer than necessary.
2) When the same column appears on more than one table, it should have
the same name. This is clearer to users (both end users and
developers), and many query-building tools will infer relationships
based on column names which match, which can be very helpful.
3) Views should not have to rename all the underlying columns, which
they would need to in order to adhere to the standard.
4) Having columns on one table carry the prefix of another table is
confusing (except perhaps in the case of foreign keys).

What other arguments can be made for or against these column prefixes?

BTW, our primary development data base is Sybase, but we have (and
will have, I'm sure) others (Oracle, MS Access, et al); I'd like to
address this globally.

Thanks!

--------------------------------------------------------------------------
David Mullen              *** Any opinions expressed are mine, and not ***
Emjay Corporation         *** necessarily those of Emjay Corporation.  ***
Milwaukee, WI

Fight spam by joining CAUCE - Coalition Against Unsolicited Commercial Email
                http://www.cauce.org/

 
 
 

Naming Convention for Columns

Post by Dave Bende » Fri, 06 Mar 1998 04:00:00


Sounds like a good little religious war you've got going. Not that a little
battle isn't good now and then.

I'll side with you, partly because it was you who asked, but mostly because
of the second point you raise. SQL Server itself, I think, can make inferred
joins on fields that match in name and type. The proposed prefixing scheme
would disrupt that.

That's my two cents. Lemme know who wins....

 
 
 

Naming Convention for Columns

Post by Alvin Sylvai » Sat, 07 Mar 1998 04:00:00




Quote:> Hello all,

Howdy doo!

Quote:> We are setting up new database naming conventions, and I'd like to
> hear other people's thoughts on what they consider to be important
> considerations.

First off, I hate naming conventions altogether.  Most important:
do one thing, and do it consistently.  But don't have heartburn
if someone doesn't quite come up to snuff.

We had three different spellings of "invoice number":
   invc_nbr, invc_no, invc_num.

Ouch.

The problem in writing code for this mess was remembering which
table had which spelling, particularly in joins.  You compile and
test something three times before you get it right.  We fixed the
problem before it got too far.

But I still hate naming conventions, because there's always going
to be the one situation where you're going to be the only person
on the planet who cares how something is named: you, that is, and
the anal-retentive co-worker or code-auditor who's only joy in life
is pointing out your failure to "follow the rules."

One rule you might want to consider, and the reason for it: name
the columns with long, self-descriptive, correctly spelled words.
Ie, instead of "invc_nbr", it should be "InvoiceNumber".  Or,
perhaps, "Invoice_Number".  Again, do it consistently: that way,
you don't have to *remember* whether or not an underline is in
the word: it either always is or always isn't.

In retrospect, I really wish we'd done something like this.
Too late now.

The reason is simple: we're going to be converting most of our
code from running on the sparc server to running on the PC client.
We'll be using Delphi.  Guess what?  You can place a "matrix" of
query result sets right on the screen, and the default is to use
the *actual* *column* *names*!!

Well, imagine the column names are "invc_no."  Real easy for a user
to figure out, yes?  No?  No.  So, you have to add extra work to
change the column names on the screen.  Work that could have been
saved if the column name was "Invoice_Number".

Quote:> In particular, I'd like to know how people feel about prefixing the
> names of columns in a relational data base with a short prefix
> representing the table to which the column belongs. (Foreign keys
> would retain the prefix of the foreign table, i.e., the table being
> referred to. This would also be true for denormalized, redundant
data:
> the redundant columns would carry the prefix of the "owner"/master
> table.) The lead developer for this project is strongly in favor of
> using such prefixes; they were used here in the past in the DBAM data
> base being replaced. He likes not having to specify the name of the
> table when he mentions the column in code, and also feels that the
> prefix helps remind the developer/user of which table they're working
> with.

> I prefer not to use such prefixes. The reasons I have given are:

> 1) It's redundant. If a column exists on more than one table and the
> reference is ambiguous, use "table.column". It also actually makes
the
> column name longer than necessary.

Agreed.  100%.  Your lead developer must have come fresh out of a
COBOL/ISAM shop.  Or worse.  Get with it, people, it's almost the
21st century for pete's sake!!  We don't flip switches in binary on
the front panel anymore!  I haven't used my hex/decimal calculator
in *years*!!

Quote:> 2) When the same column appears on more than one table, it should
have
> the same name. This is clearer to users (both end users and
> developers), and many query-building tools will infer relationships
> based on column names which match, which can be very helpful.

Agreed.  100%.

Quote:> 3) Views should not have to rename all the underlying columns, which
> they would need to in order to adhere to the standard.

Only if your lead developer is anal-retentive ...

Quote:> 4) Having columns on one table carry the prefix of another table is
> confusing (except perhaps in the case of foreign keys).

Foreign keys is the only place to prefix a table name, and even there,
it needs to *make* *sense*.

For example, you have a company table; keyed by "alias" or "code"
or what-have-you.  Referenced, as you've mentioned, as "company.code".
Then you have an invoice table, and you need to store both the buying
company and the selling company.  (Your company might be one of several
subsidiaries, all kept in the same database.)

Do you name the column, "buyer_company_code" and "seller_company_code"?
Not in my shop you don't!  "buy_company" and "sell_company", thank you
very much.  Only an idiot will have trouble figuring out the dual join
to the company table.

Quote:> What other arguments can be made for or against these column

prefixes?

The names don't need to be system-wide unique, which is the only
possible reason for prepending any sort of code at all.  Long time
ago, I worked in a real-time environment where each running task
had to have a unique name: Ok, in that case, maybe you need a rigid
naming convention.  But I doubt if anyone is still doing a whole lot
of development work on PDP-11's.

Nowadays, memory is cheap, and programmer time is expensive.  The
less time it takes for someone to *figure* *out* what's going on,
the better.  Rigid naming conventions that require a person to learn
a new "language" before becoming useful are counter-productive.

Just my two cents worth.

A.

 
 
 

Naming Convention for Columns

Post by Allan Burge » Sat, 07 Mar 1998 04:00:00


This comment does not solve your argument.

But some of the low-end CASE tools make the assumption that the column names
must be unique in the database and force you into the standard of tablename
prefixes for columns.

Allan


> Hello all,

> We are setting up new database naming conventions, and I'd like to
> hear other people's thoughts on what they consider to be important
> considerations.

> In particular, I'd like to know how people feel about prefixing the
> names of columns in a relational data base with a short prefix
> representing the table to which the column belong. ........

 
 
 

Naming Convention for Columns

Post by Todd Bo » Sat, 07 Mar 1998 04:00:00






>First off, I hate naming conventions altogether.  Most important:
>do one thing, and do it consistently.  But don't have heartburn
>if someone doesn't quite come up to snuff.

>We had three different spellings of "invoice number":
>   invc_nbr, invc_no, invc_num.

>Ouch.

>The problem in writing code for this mess was remembering which
>table had which spelling, particularly in joins.  You compile and
>test something three times before you get it right.  We fixed the
>problem before it got too far.

So, let me see, you hate naming conventions, but then a situation arises
that really pisses you off, but which could have been avoided by, yes,
having naming conventions!  

Quote:>One rule you might want to consider, and the reason for it: name
>the columns with long, self-descriptive, correctly spelled words.
>Ie, instead of "invc_nbr", it should be "InvoiceNumber".  Or,
>perhaps, "Invoice_Number".  Again, do it consistently: that way,
>you don't have to *remember* whether or not an underline is in
>the word: it either always is or always isn't.

Be consistent.  NEVER mix upper and lower case in column names.  You
won't believe how much hair you'll rip out the 5th time you've retyped
a simple query b/c you have mixed case in Sybase.

You can't get away from SOME abbreviations in column names...the best
you can hope ful is to be predictable with your abbreviations.
cntrl for control, num for number, ID for identification , etc etc.

As you design your system, before you create the physical entities
sort through your attributes by physical name and shake out any
inconsistencies.  It doesn't take too long.  I also advocate standard
user defined datatypes linking up w/ the column names (i.e., define
a standard for height and then incorporate hgt or h in the column names).

boss

 
 
 

Naming Convention for Columns

Post by Jeremy Rickar » Sat, 07 Mar 1998 04:00:00


The main thing is to have a systematic naming standard, and then stick
to it rigorously.  If you do even that you'll be doing better than the
average shop, in my experience.

--
Jeremy Rickard

 
 
 

Naming Convention for Columns

Post by David William » Sat, 07 Mar 1998 04:00:00




Quote:>This comment does not solve your argument.

>But some of the low-end CASE tools make the assumption that the column names
>must be unique in the database and force you into the standard of tablename
>prefixes for columns.

  I prefer table name prefixs. When talked to others I if say

  cd_key

  then it is obvious which column in which table is wrong

  "Yeah, it was job 5000 cm_key for the company was wrong."

  rolls off the tongue better than

  "Yeah, it was job 5000 company_manager.cm_key for the company was
   wrong."

  the dot tens to breaj up the flow...

>Allan


>> Hello all,

>> We are setting up new database naming conventions, and I'd like to
>> hear other people's thoughts on what they consider to be important
>> considerations.

>> In particular, I'd like to know how people feel about prefixing the
>> names of columns in a relational data base with a short prefix
>> representing the table to which the column belong. ........

--
David Williams

Maintainer of the Informix FAQ
 Primary site (Beta Version)  http://www.smooth1.demon.co.uk
 Official site                http://www.iiug.org/techinfo/faq/faq_top.html

I see you standin', Standin' on your own, It's such a lonely place for you, For
you to be If you need a shoulder, Or if you need a friend, I'll be here
standing, Until the bitter end...
So don't chastise me Or think I, I mean you harm...
All I ever wanted Was for you To know that I care

 
 
 

Naming Convention for Columns

Post by ear » Sun, 08 Mar 1998 04:00:00


i work in a 'c' shop.  we are converting a   ibm series/1    for you moldy
oldies!
application to c with db2.
our standard is all caps with underscores    MEDIA_DATE
when we select a column from the db we move the column to a
structure which is the table name   TRANS_DETAIL.MEDIA_DATE
this keeps any command line queries from adding to my carpal tunnel   ; )
like some others have said,   always use  num  or  nbr   or whatever you decide
another thing we did was designate  _FLAG as an 0 or 1 field
and _CODE  as 1,2,5,a,b,c   ect
have fun,
elaine


> Hello all,

> We are setting up new database naming conventions, and I'd like to
> hear other people's thoughts on what they consider to be important
> considerations.

> In particular, I'd like to know how people feel about prefixing the
> names of columns in a relational data base with a short prefix
> representing the table to which the column belongs. (Foreign keys
> would retain the prefix of the foreign table, i.e., the table being
> referred to. This would also be true for denormalized, redundant data:
> the redundant columns would carry the prefix of the "owner"/master
> table.) The lead developer for this project is strongly in favor of
> using such prefixes; they were used here in the past in the DBAM data
> base being replaced. He likes not having to specify the name of the
> table when he mentions the column in code, and also feels that the
> prefix helps remind the developer/user of which table they're working
> with.

> I prefer not to use such prefixes. The reasons I have given are:

> 1) It's redundant. If a column exists on more than one table and the
> reference is ambiguous, use "table.column". It also actually makes the
> column name longer than necessary.
> 2) When the same column appears on more than one table, it should have
> the same name. This is clearer to users (both end users and
> developers), and many query-building tools will infer relationships
> based on column names which match, which can be very helpful.
> 3) Views should not have to rename all the underlying columns, which
> they would need to in order to adhere to the standard.
> 4) Having columns on one table carry the prefix of another table is
> confusing (except perhaps in the case of foreign keys).

> What other arguments can be made for or against these column prefixes?

> BTW, our primary development data base is Sybase, but we have (and
> will have, I'm sure) others (Oracle, MS Access, et al); I'd like to
> address this globally.

> Thanks!

> --------------------------------------------------------------------------
> David Mullen              *** Any opinions expressed are mine, and not ***
> Emjay Corporation         *** necessarily those of Emjay Corporation.  ***
> Milwaukee, WI

> Fight spam by joining CAUCE - Coalition Against Unsolicited Commercial Email
>                 http://www.cauce.org/

 
 
 

Naming Convention for Columns

Post by Alvin Sylvai » Sun, 08 Mar 1998 04:00:00








> >First off, I hate naming conventions altogether.  Most important:
> >do one thing, and do it consistently.  But don't have heartburn
> >if someone doesn't quite come up to snuff.

> >We had three different spellings of "invoice number":
> >   invc_nbr, invc_no, invc_num.

> >Ouch.

> >The problem in writing code for this mess was remembering which
> >table had which spelling, particularly in joins.  You compile and
> >test something three times before you get it right.  We fixed the
> >problem before it got too far.

> So, let me see, you hate naming conventions, but then a situation
arises
> that really pisses you off, but which could have been avoided by,
yes,
> having naming conventions!

You got me there.  What can I say?  We didn't need to have a
"naming convention" per se, just a consistent way of naming
things.  Eg, we could have named it "invc_no" every where for
"Invoice Number", but still use a full spelling for something
else, such as "company_name", vs. "co_name".

We fixed it, but you have no idea how much code we broke
fixing it!  Which had to be fixed.

Quote:> >One rule you might want to consider, and the reason for it: name
> >the columns with long, self-descriptive, correctly spelled words.
> >Ie, instead of "invc_nbr", it should be "InvoiceNumber".  Or,
> >perhaps, "Invoice_Number".  Again, do it consistently: that way,
> >you don't have to *remember* whether or not an underline is in
> >the word: it either always is or always isn't.

> Be consistent.  NEVER mix upper and lower case in column names.  You
> won't believe how much hair you'll rip out the 5th time you've
retyped
> a simple query b/c you have mixed case in Sybase.

This is very good advice, particularly considering that you never
know when you'll have to port to a database that doesn't support
mixed case anyway, and it'll just be dumb luck that thru the process
of mangling by multiple maintainers, to get something like both
"lcFlag" and "lcflag" in the same table.  (Hey, in 200+ columns
and the 8th person to "fix" something, it could happen!)

A.

 
 
 

Naming Convention for Columns

Post by Louis Cohe » Sun, 08 Mar 1998 04:00:00


I have done this both ways, and I feel strongly about it:

Column prefixes are just stupid:

- All good code should always use a table alias in every reference to any
column, so the column prefix is not needed:

    select ai.invoice_number, pv.vendor_name
    from   ap_invoices ai, po_vendors pv
    where ai.pv_vendor_id = pv.vendor_id
     etc.
(Define standard table aliases in a CASE tool)

- It's a lot of extra typing for no reason; column prefixes contribute
nothing to maintainability

- FK columns should include the alias of the table that the column points to
(see above)

Regards

Louis Cohen


>Hello all,

>We are setting up new database naming conventions, and I'd like to
>hear other people's thoughts on what they consider to be important
>considerations.

>In particular, I'd like to know how people feel about prefixing the
>names of columns in a relational data base with a short prefix
>representing the table to which the column belongs. (Foreign keys
>would retain the prefix of the foreign table, i.e., the table being
>referred to. This would also be true for denormalized, redundant data:
>the redundant columns would carry the prefix of the "owner"/master
>table.) The lead developer for this project is strongly in favor of
>using such prefixes; they were used here in the past in the DBAM data
>base being replaced. He likes not having to specify the name of the
>table when he mentions the column in code, and also feels that the
>prefix helps remind the developer/user of which table they're working
>with.

>I prefer not to use such prefixes. The reasons I have given are:

>1) It's redundant. If a column exists on more than one table and the
>reference is ambiguous, use "table.column". It also actually makes the
>column name longer than necessary.
>2) When the same column appears on more than one table, it should have
>the same name. This is clearer to users (both end users and
>developers), and many query-building tools will infer relationships
>based on column names which match, which can be very helpful.
>3) Views should not have to rename all the underlying columns, which
>they would need to in order to adhere to the standard.
>4) Having columns on one table carry the prefix of another table is
>confusing (except perhaps in the case of foreign keys).

>What other arguments can be made for or against these column prefixes?

>BTW, our primary development data base is Sybase, but we have (and
>will have, I'm sure) others (Oracle, MS Access, et al); I'd like to
>address this globally.

>Thanks!

>--------------------------------------------------------------------------
>David Mullen              *** Any opinions expressed are mine, and not ***
>Emjay Corporation         *** necessarily those of Emjay Corporation.  ***
>Milwaukee, WI

>Fight spam by joining CAUCE - Coalition Against Unsolicited Commercial
Email
>                http://www.cauce.org/

 
 
 

Naming Convention for Columns

Post by Matthew O. Persic » Mon, 09 Mar 1998 04:00:00


Quote:> > Be consistent.  NEVER mix upper and lower case in column names.  You
> > won't believe how much hair you'll rip out the 5th time you've
> retyped
> > a simple query b/c you have mixed case in Sybase.

> This is very good advice, particularly considering that you never
> know when you'll have to port to a database that doesn't support
> mixed case anyway, and it'll just be dumb luck that thru the process
> of mangling by multiple maintainers, to get something like both
> "lcFlag" and "lcflag" in the same table.  (Hey, in 200+ columns
> and the 8th person to "fix" something, it could happen!)

Ah, but what happens when your all lowercase, underbar separated column
names get sucked into a C++ class? Most of the code I see in C++ these
days is capital letter separated, not all lowercase and underbar
separated. Especially if you know you won't be porting to something so
primative in this day and age that it doesn't support letter case. As
for which to actually choose, you tell me which has the best combination
of space savings (and keystoke typing savings) and readability at 2am
fixing a hong kong production problem from NYC:

        setldateovrd
        setl_date_ovrd
        setlDateOvrd

You can make a case for the second or third but not the first.

Why am I sticking my $0.02 into this potential religious war?

 
 
 

Naming Convention for Columns

Post by Alvin Sylvai » Tue, 10 Mar 1998 04:00:00




Quote:> > > Be consistent.  NEVER mix upper and lower case in column names.
You
> > > won't believe how much hair you'll rip out the 5th time you've
> > retyped
> > > a simple query b/c you have mixed case in Sybase.

> > This is very good advice, particularly considering that you never
> > know when you'll have to port to a database that doesn't support
> > mixed case anyway, and it'll just be dumb luck that thru the
process
> > of mangling by multiple maintainers, to get something like both
> > "lcFlag" and "lcflag" in the same table.  (Hey, in 200+ columns
> > and the 8th person to "fix" something, it could happen!)

> Ah, but what happens when your all lowercase, underbar separated
column
> names get sucked into a C++ class? Most of the code I see in C++
these
> days is capital letter separated, not all lowercase and underbar
> separated.

True enough, but C++ doesn't *FORCE* you to follow that convention.
A case-insenstive system *forces* you to follow certain constraints.

Quote:> Especially if you know you won't be porting to something so
> primative in this day and age that it doesn't support letter case.

You can never be that clarvoyant.  Or, I should say, you can't be
that clarvoyant YET.  Just like it no longer makes sense to code
for an IBM PC with only 640 kilobytes of RAM in it ... but, at one
time, it was foolish to assume that more than a few percentage of
your potential customer base had upgraded to a full meg or more.

I'm thinking specifically of Oracle, which still defaults to case
insensitivity.  It's only the Numero Uno database on the planet.
I believe it *can* be case sensitive, but I haven't found out how
to set that up.  Since everything we have currently is all lower
case, I'm not motivated to investigate.

Quote:> As
> for which to actually choose, you tell me which has the best
combination
> of space savings (and keystoke typing savings) and readability at 2am
> fixing a hong kong production problem from NYC:

>    setldateovrd
>    setl_date_ovrd
>    setlDateOvrd

> You can make a case for the second or third but not the first.

It's a matter of taste.  Keystrokes should rarely be a consideration:
the two seconds you save could cost somebody an hour trying to figure
out what you're trying to say.  From that point of view, your second
two examples are virtually identical.  The first suffers problems
such as "mans_laughter" vs. "manslaughter".

Quote:> Why am I sticking my $0.02 into this potential religious war?

Because it's more enjoyable than doing real work, of course!  :-)

A.

 
 
 

Naming Convention for Columns

Post by Alvin Sylvai » Tue, 10 Mar 1998 04:00:00








> >First off, I hate naming conventions altogether.  Most important:
> >do one thing, and do it consistently.  But don't have heartburn
> >if someone doesn't quite come up to snuff.

> >We had three different spellings of "invoice number":
> >   invc_nbr, invc_no, invc_num.

> >Ouch.

> >The problem in writing code for this mess was remembering which
> >table had which spelling, particularly in joins.  You compile and
> >test something three times before you get it right.  We fixed the
> >problem before it got too far.

> So, let me see, you hate naming conventions, but then a situation
arises
> that really pisses you off, but which could have been avoided by,
yes,
> having naming conventions!

Actually, I really should add to this the fact that the thing
that created this confusion in the first place was our *changing*
from a rather loose set-up to a "rigorous" naming convention!

If we had simply left everything alone (it was previously
"invoicenumber"), we would have saved ourselves some considerable
heartburn!

The main problem in naming conventions this way (ie, using "shortcut"
names) is coming up with unambiguous shortcuts for everything (because
the guy who came up with the idea is fairly lazy when it comes to
typing)
vs. words that are "long-enough-for-any-idiot-to-understand."

What you have to do, and what we did, was create a "glossary" of
"company accepted" shortcuts.  Naturally, the only person who read
and followed this glossary was the guy who wrote it.  (I mean, come
ON, already: changing a perfectly understandable "FLAG" to cryptic
"FLG" in order save one character?  Is it "DT" or "DTE" or "DAT"
instead of "DATE"?  All this confustion just to follow this
"consistency" bug-a-boo?)

So, in other words, in order to follow this new naming convention,
we all had to learn a new "vocabulary."  On top of all the other *
we had to learn (we were proficient in Sybase, but the customer wanted
Oracle).

My personal preference is for self-documenting variables, including
table and column names, using shortcuts only where necessary.  Of
course, you still have the problem with ambiguous and multiple full
spellings of words, but I think that problem isn't anywhere near as
severe as that of the utter *reams* of possible shortcuts for words!

Sure, the programmer has to type a little more: but statistics prove
that only 20% (or less) of programmer time is spent typing anyway,
so what's the big deal?  (Actually, it's something like 80%
maintenance,
and 20% everything else.)  You want double your 80% fraction in order
to save on your 20% fraction?  Penny-wise and Pound-foolish!

A.

 
 
 

Naming Convention for Columns

Post by Jim » Tue, 10 Mar 1998 04:00:00


My .02 is is to make columns all uppercase.  No underscores.  No confusion.  Never.

--
Regards,
Jim
|> > Be consistent.  NEVER mix upper and lower case in column names.  You
|> > won't believe how much hair you'll rip out the 5th time you've
|> retyped
|> > a simple query b/c you have mixed case in Sybase.
|>
|> This is very good advice, particularly considering that you never
|> know when you'll have to port to a database that doesn't support
|> mixed case anyway, and it'll just be dumb luck that thru the process
|> of mangling by multiple maintainers, to get something like both
|> "lcFlag" and "lcflag" in the same table.  (Hey, in 200+ columns
|> and the 8th person to "fix" something, it could happen!)
|
|Ah, but what happens when your all lowercase, underbar separated column
|names get sucked into a C++ class? Most of the code I see in C++ these
|days is capital letter separated, not all lowercase and underbar
|separated. Especially if you know you won't be porting to something so
|primative in this day and age that it doesn't support letter case. As
|for which to actually choose, you tell me which has the best combination
|of space savings (and keystoke typing savings) and readability at 2am
|fixing a hong kong production problem from NYC:
|
| setldateovrd
| setl_date_ovrd
| setlDateOvrd
|
|You can make a case for the second or third but not the first.
|
|Why am I sticking my $0.02 into this potential religious war?

 
 
 

Naming Convention for Columns

Post by Billy Verreynn » Tue, 10 Mar 1998 04:00:00



> My .02 is is to make columns all uppercase.  No underscores.
> No confusion.  Never.

I use numbers, first column is C1, second column C2 etc. Tables are T1, T2,
.. and stored proc are of course P1, P2 and so on. It confuses the hell out
of the users, scares the shit out of the developers, cause IS managers to
resign and -nobody- messes with any of my databases.

One DBA, one leadpipe!

a Scorched Earth Party supporter,
Billy
--
Earth First! We will stripmine the other planets later.

 
 
 

1. Naming conventions for columns

All,

I'm using ADO to access a FileMaker database.  FileMaker allows the

(column in SQL) names.

I was getting some bizarre crashes in VB while manipulating ADO
recordsets that contained such column names.  Removing the characters
seems to have helped.  Note that I wasn't explicitly referencing these
field names in any queries.

I couldn't find information in the ADO docs on naming conventions,
especially which characters are legal or illegal in column names for
both SQL and ADO.  Can anyone point me to a good reference?

Thanks,

--
Chip Calvert - Celtic Wolf, Inc.
Software Design and Development, Project Management,
Technical Writing, Research
(703) 580-0210

2. Data Modeling Question

3. Naming Convention for Columns

4. Additional material for Visual Cafe Pro

5. Save an array to an OLE field in Access from VB?

6. GENSCRNX ?

7. Naming Convention for Columns ..continued...

8. Naming Convention for Columns

9. naming conventions for table/column names

10. column name convention