I don't use notation for table name prefix, so my field name often are
already ok as display labels (in grids of IB_Edit with autolabel).
This way I save a lot of time (of course, sometime their name is too
cryptic, so I have to define a display name).
In your example I imediatly have (undersocre is automatically removed
by IBO):
ID
NAME FIRST
NAME LAST

Just to point out "the cons" ;)
regards
Marco Menardi

--- In IBObjects@yahoogroups.com, "Brian K. Woods" <brian@e...> wrote:
> > From: paulfilmer <pfilmer@b...>
> > [mailto:pfilmer@b...]
> > Sent: Wednesday, February 05, 2003 6:26 PM
> > To: IBObjects@yahoogroups.com
> > Subject: Re: [IBO] overriding SQLName property / handling keywords
> >
> >
> > Thanks Helen
> >
> > I will just rename the field to a non-keyword and fix up the
> > references in the code. There aren't too many of them and they
> > wouldn't be too hard to find.
> >
> > Renaming the field in the actual gdb file to have double quotes is
> > likely to just confuse people down the track :)
> >
>
> A friendly observation while you're renaming... This ranks up there with
> hungarian notation - some like it, some don't - but I always use a
prefix
> for
> table field names to prevent the very problem you ran into.
> For example, for a table DONOR one might use fields DNR_ID,
DNR_NAME_FIRST,
> DNR_NAME_LAST, etc. etc.
>
> It's not that much extra to type, and it could save you unnecessary work
> down the road ;-)
> An added benefit is that it makes your sql self documenting, as well as
> makes it nearly impossible
> to fall into the trap of accidentally not using alias.fieldname in
complex
> statements, since
> no two fields in the database will have the exact same name and thus
cannot
> be ambiguous (except for
> self-joins).
>
> FWIW,
> Good luck recoding,
> Brian