>Hi Doug,
>
>>Actually, I think this is a waste of time in xBase too. It makes sense with variables because xBase is weakly typed (meaning you can put any value into any variable), so a naming convention tells the developer what data type is expected in a variable. However, fields in tables are strongly typed, so there's no need to use a naming convention to tell you the expected data type; just look at the table structure.
>>
>>My 2 cents (and I'm guessing I'll hear some opposing opinions <g>).
>
>I would argue strongly in favour of some form of naming convention.
>
>We have a VFP application which can use VFP, Oracle or SQL Server as a back-end.
>
>One of the fields was called Percent - this seemed ok in VFP or Oracle but caused problems in SQL Server [apparently because it is a reserved word]. Queries to the the back-end including this field caused syntax errors.
>
>I would argue that to use no naming convention, you would have to be sure not to use reserved words [both in VFP and the back-end]. Your choice of field/table names would also have to be governed by reserved words in future versions of the backend.
>
>I believe Percent was ok in SQL Server 6.5, but the problem arose in version 7.0.
>
>Best.
>
>Matt.

That is correct. from BOL:

These reserved keywords are new to SQL Server 7.0:

BACKUP
DENY
PERCENT
RESTORE
TOP