Any option to interpret the length of varchar as chararcters?

[MCMartin]

Does any option exist to generally let the database interpret the length of varchar columns as number of characters instead of number of bytes?

E.g. when loading an existing table definition into an UTF-8 database the columns might be too small for the data. A workaround is to re-define the varchar columns with an explicit character option, but a general option would be more convenient.

example:

old db: varchar(5)
new utf-8 db requires: varchar(5 character)

[Breck_Carter]

Turn this into a "product suggestion" for something like SET OPTION PUBLIC.default_varchar_length_semantics = 'byte' (default) or 'character'... I'll support it even though I don't need it. I can see the need.

[MCMartin]

What would be the official way to suggest such an enhancement?

[VolkerBarth]

"the official way to suggest"

Don't know. However, AFAIK, iAnywhere/Sybase/SAP staff members have promised to take notice of questions in this forum tagged as "product-suggestion" - probably particularly those with up-votes.

[Former Member]

You could switch to using the nvarchar datatype in your new database. The length specified for nvarchar is characters, not bytes.
dcx link

[VolkerBarth]

...however, that would also require to change the table definition, and that is not desired here, according to Martin.

BTW: Would that not possibly have further implications (a different default collation at least)?

[Former Member]

Yes, the table def would have to change in the new UTF8 database - but it has to change regardless because the current schema is not working. There may be collation issues to deal with, but there already are if he is moving from a non-UTF8 database to a UTF8 database, so it is not really any extra work to deal with it.

[VolkerBarth]

Apparently, that situation could be handled rather easy when one uses user-defined domains, i.e. has defined something like DT_MYCHAR_50 which could be re-defined in the new database from CHAR(50) to CHAR(50 CHAR), so instead of altering many tables/view/STPs one would only have to adapt a few domains - but yes, that's a post-mortem hint:)