> > > On 24-7-2015 21:37, Aldo Caruso aldo.car...@argencasas.com > [firebird-support] wrote: > > > I wonder if the following strategy has any pitfall: > > > > 1) Create the temporary field of the right character set > > 2) Fill it with data, using CAST to OCTETS as suggested by "The Firebird > > Book" > > 3) Alter the original field type, changing it to the right character set > > 4) Fill it with data from the temprorary field > > 5) Drop the temporary field > > > > Notice that only the 2nd step could raise conversion errors, and you > > have to manage them there. > > In the 4th step no error could occur since both fields are of the same > > type and character set. > > El 25/07/15 a las 05:45, Mark Rotteveel m...@lawinegevaar.nl > [firebird-support] > escibió: > > That would probably work, but you might have to recreate triggers, views > and stored procedures anyway. I am not sure if the generated BLR > contains assumptions/behavior based on the original format. > > On Sat, Jul 25, 2015 at 2:22 PM, Aldo Caruso aldo.car...@argencasas.com [firebird-support] <firebird-support@yahoogroups.com> wrote:
> > > So, to be conservative, let's use the original process as recommended by > the book. > Thank you. > You might try your original approach because BLR is actually a very high level language - albeit binary. It doesn't include datatype information, string sizes, collations, or character set. All that is supplied when the request is compiled into an execution tree. The purpose of BLR was to allow a database to encode user requests in a network and machine friendly format that could support SQL, QUEL, and DEC's database language which became GDML. Since all but SQL are now dead, BLR is an artifact without benefit - serving only to remind the ancient that the world could have been very different and much more interoperable.. Anyway, you'll have to recompile your triggers etc., but the BLR should be OK. Cheers, Ann
