On 29-10-2018 21:21, [email protected] [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
