Re: Rif: [firebird-support] Chararacter set NONE to ISO8859_1

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

On Sun, Jul 26, 2015 at 3:19 PM, Aldo Caruso aldo.car...@argencasas.com
[firebird-support]  wrote:

>
>
>
> Why do you say that "All but SQL are now dead and BLR is an artifact
> without benefit ?"
>

There is absolutely no interest in interoperability between database
companies.  Claiming to support SQL is good enough.  Nobody expects an
application to work transparently between databases, let along across
databases.


> And, if BLR doesn't include datatype information, why do you say that I
> have to recompile triggers and SP anyway ?
>

You don't have to recreate the procedure from the SQL definition.  However
you'll have to recompile the BLR into an execution tree - which happens
anytime you shut the database down.

Cheers,

Ann

Re: Rif: [firebird-support] Chararacter set NONE to ISO8859_1

[Aldo Caruso aldo.car...@argencasas.com [firebird-support]]

Thanks for your answer.

I'm a bit confused by your two final phrases.
Why do you say that "All but SQL are now dead and BLR is an artifact 
without benefit ?"
And, if BLR doesn't include datatype information, why do you say that I 
have to recompile triggers and SP anyway ?


Aldo

El 26/07/15 a las 14:06, Ann Harrison aharri...@ibphoenix.com 
[firebird-support] escibió:



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

Re: Rif: [firebird-support] Chararacter set NONE to ISO8859_1

[Ann Harrison aharri...@ibphoenix.com [firebird-support]]

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