On 28.06.2017 at 22:58, Ann Harrison aharri...@ibphoenix.com [firebird-support] wrote: > Not if you have indexes, a declared primary key, or a declared unique > constraint. The index keys are a transformation of the value into a format > that produces the desired ordering through binary comparisons.
Any chance that setting the RDB$RELATION_FIELDS.RDB$COLLATION_ID and then backing up and restoring the whole database would re-create the index trees properly? > Not safe, won't work, and will produce very odd results on range queries on > any > index. Or, say, a query that causes Firebird to return rows in index > order. Agreed, but again... restoring the database from a backup rebuilds all indices anyway, the piece of information I lack is: would they be rebuilt in the proper (new) collation? >> Also, does the RDB$RELATION_FIELDS.RDB$COLLATION somehow depend on the >> default character set of the database, or is it universal (i.e. does the >> collation code from RDB$RELATION_FIELDS.RDB$COLLATION always mean the >> same, or does a single code mean different collations in databases with >> different default character sets)? >> > The format of the keys depends on the character set - different character > sets > have different meanings for some byte values, which collate differently. Yes, that's clear, but my question concerned the collation id values kept in RDB$COLLATION_ID. Suppose you have a database with the default character set WIN1250. Setting the PXW_PLK collation results in RDB$COLLATION_ID set to 3 (checked that). Is it possible that the same value 3 would correspond to a different collation in another database, e.g. one with the default character set WIN1252? Or is 3 strictly bound to PXW_PLK and always means PXW_PLK, regardless of the character set of the database? I suppose this is not the case, 'cause setting a column collation to WIN1250 in a database with the default character set WIN1250 results in RDB$COLLATION_ID = 0 (and I don't think WIN1250 is so special as to be given the value of 0). On a second thought, don't waste your time on it. I'll just create those two DBs, see for myself, and post a quick update. > Good luck, > > Ann Thank you for your time and valuable information. Best regards Tomasz
