Keyword Quoting on Table Names

The quoting is useful, but our coding guidelines require [] style quoting to be used only where essential. This is effectively keywords only and so generates sql like...

SELECT * FROM [Group] INNER JOIN GroupType ON ...

Is this possible? (I appreciate that we should probably avoid Keywords for table names, but in practice it doesn't happen! :))

Many thanks...Karl.

There is an option available for controlling the "quoting" feature. On the DB Options page you can change "Always Add Delimiters" option from None to […]. This will do what you want.

Actually, [...] always adds delimiters. I think he is asking for an option that will use delimiters when the name matches on a keyword, but don't use them otherwise. I would like that feature too.

Ok, I will add this as an enhancement request for addition in the following maintenance releases.

My 2 cents: I personally think this is a bad idea. In the first place keywords should not be used as object/column names. If a naming mistake has been made, it should be corrected at the root, instead of arm twisting using and coding various workarounds, using ANSI incompatible proprietary extensions like [ ] brackets to deal with this mistake, making non-portable applications with potential upgrade problems, data backup and conversions issues, etc.., you get my point.

Yes, legacy (or inherited) apps are a pain. Please help us to deal with them. Also new keywords can be useful and annoying at the same time.

Gentlemen, I've got good news for you. This appears to be very easy, we made a tweak in the code that will wrap in delimiters any keyword matching name. Moreover, since you control the keyword list you can add additional keywords as required. This tweak will be available in beta build 3.0.26 planned for next week.

Wonderful! Thankyou!

I agree that it isn't desirable to use keywords, but there are a couple of cases where it seems to happen:

1. Legacy apps that I seem to inherit! Changing table names late in development can be time consuming since SPs, object models, etc are already written.

2. Apps ported from other systems where keywords vary (Group was a bad example, sorry).

I can assure you that I don't create schemas like this, but I do have to cope with them. Thanks again. :)