Hello all...we've been migrating our databases from ASA
9.0.2 to SQL Anywhere 11.0.1 with great success. The only
problem I have encountered is that if you migrate a table
that has a column which is a reserved word in SQLAnywhere
11.0.1, i.e. 'comment', the SQL Anywhere 11.0.1 on-line help
says that it must be enclosed in double quotes, i.e.
"comment". Additionally, the migration documentation states
that all references to the reserved word should be changed
to a different name, ie 'comment' would become '@comment'...
The problem with these work arounds is that I would have to
change my column names from many tables. My question is: Is
there anyway a database property could be set so that I
would not have to do this? Any info would be greatly
appreciated.

Hi Mark,

Not sure if this helps but I would do an analysis on the number of fields
that this affects. If it is low, just change the names and change any code
calling them.

(Note: If customers use reporting tools like Crystal Reports, they'd have to
change them too).

I can't imagine you'd have that many fields with this problem though.

The reason I say this is because, the hassle of a workaround and maintaining
it going forwards might work out high in the long term.

Cheers,

Shao

<Mark> wrote

Hi Mark,

If this is too large an undertaking to change your code and columns, see
the 'non_keywords' database option in the documentation:
http://dcx.sybase.com/1101en/dbadmin...ds-option.html

(Keeping in mind that all words appearing in this list will now be
unavailable and can cause syntax errors if used - changing the option as
needed would be a workaround to that issue, or quote the columns
appropriately).

Cheers,

Mark wrote:
--
Jeff Albion, Sybase iAnywhere

iAnywhere Developer Community :
http://www.sybase.com/developer/libr...ere-techcorner
iAnywhere Documentation : http://www.ianywhere.com/developer/product_manuals
SQL Anywhere Patches and EBFs :
http://downloads.sybase.com/swd/summ...&timeframe =0
Report a Bug/Open a Case : http://case-express.sybase.com/cx/

Mark,
I haven't used this myself but the non_keywords option may do the trick.

AFAIK, the usage of reserved words as column names written within double
quotes is SQL Standard and no workaround as such. However it seems
sensible to avoid this

HTH
Volker

Mark wrote:

These suggestions were outstanding and they solved my
problem. Thanks to all who responded!!!