On 29-10-2018 21:21, sboydlns@... [firebird-support] wrote:

> So what you and Helen are telling me is that I should change the
> database to use UTF8. Correct?

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.

> What are the implications of changing from CharSet = None to CharSet =
> UTF8?

The selection of character sets has a number of potentially far-reaching
implications that I can't simply cover in an email. But a number of
effects are:

- 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.

> Will this affect already stored data in any way? Will this affect
> my existing programs by somehow transmuting the data being returned to
> me?

If the bytes currently stored in your columns are already valid UTF8,
then that shouldn't occur. If they aren't valid UTF8, but a different
character set, you will need to convert applying the appropriate
transformations.

If your applications have been using multiple different character sets,
then you will have some pain to recover it to the correct character set
(but you'll already have that problem now as well).

>I can't afford for everything to suddenly turn to crap because I
> change the CharSet of the database. Is it possible to change the CharSet
> of individual fields instead?

Character sets are a property of the column, not of the database. The
only thing the default character set of a database does, is determine
the character set of a newly added column if no explicit character set
was specified. The default character set has no effect on existing columns.

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).

> I am still using 2.5.1 becaus e up until this moment it has done
> everything I need it to do without any problems. And I have a firm "If
> it ain't broke, don't fix it" policy. I also have about a hundred sites
> running this stuff and it is nice to have them all on the same release.
> And updating all 100 sites is simply not on for anything less than a
> full blown emergency.

On the other hand, having to do an unprepared and untested upgrade in an
emergency is a great way to miss things in release notes (for example
the need to backup and restore 2.5.1 databases when upgrading, or at
least to rebuild all compound indexes), which could possibly make the
emergency worse.

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)

A number of security vulnerabilities were fixed:

2.5.2 Security Update 1: "A remote stack buffer overflow was discovered
in the Firebird Server during March, 2013, that allows an
unauthenticated user to crash the server and opens a gate for remote
code execution."

2.5.3 Security Update 1: "The Superserver and Superclassic servers could
crash with a segmentation fault caused by a malformed network packet,
opening a vulnerability. It does not affect the Classic server."

2.5.7: "A serious security problem existed with the access to undesired
external modules, even if 'Restrict' configuration mode was specified
for UdfAccess."

And a few hundred smaller and larger bugs have been fixed and
improvements have been made.

Mark
--
Mark Rotteveel