>Well, if your application uses UTF8, then probably yes, but if you only >need a region specific character set, then using that character set >could be good enough: specifying a connection character set other than >NONE will automatically transliterate between character sets. >We can't judge what the right solution for your application will be, but >using NONE is usually the wrong decision, unless you carefully control >what your applications do. Trouble is this data is coming from an outside source. It is basically city and state names so it could contain almost anything. All Roman characters but almost any conceivable language. No way to pick a region specific character set. The whole rest of the application is English only so we have never run into problems until now. I'm thinking that just changing the columns in question to UTF8 will have to be good enough. >- it will restrict the maximum column length to max 8191 characters. >- given index column size is limited by page size, it may require you to >use smaller columns if they need an index. Not a problem since the fields in question are 50 - 100 characters max and not part of any indexes.
>In other words: you will need to change individual columns anyway (or >create a fresh new database and pump the data from the old to the new). Can I just change the character set of an existing column without having to copy the data? >And 2.5.1 is broken, it has an issue with compound indexes (see >https://www.firebirdsql.org/file/documentation/release_notes/html/en/2_5/notes-253.html) > >https://www.firebirdsql.org/file/documentation/release_notes/html/en/2_5/notes-253.html) If I understand this properly then this isn't really an issue since I always back up and restore a database when upgrading Firebird versions as a matter of course. >A number of security vulnerabilities were fixed: Security is not a big issue for us. The databases are NEVER accessible outside of the local LAN. We sell pre-packaged software to people that don't have an IT staff so hacking inside the LAN in not much of an issue. Steve
