Suppose I had a really big database. Suppose it's about 1.5 TB. Now
suppose that it's got all standard ASCII in it, with no
internationalization, and no NCHAR or NVARCHAR fields. Now suppose it's
currently set up with the default en_US.819 locale.

Got it? Good.

Now suppose a new requirement came up for internationalized data. And
suppose we wanted to use UTF8 for this internationalization. Further,
suppose we don't have an extra 1.5 TB laying around to do a huge migration.

I understand that this is the sort of suggestion that gives IBM
engineers nightmares, but what would be the problem with just magically
changing some flags somewhere so that the database thinks its locale is
en_US.UTF8 and that it has been that locale all along? Sure seems to
beat a protracted migration, and I don't see what the problem would be,
since there's no internationalized data right now...

Thoughts? Lectures? Doomsday predictions?

Thanks,

- TJG

Dear Tom,

Interesting problem.

On Feb 7, 2008 7:41 PM, Thomas J. Girsch <tgirsch@nospam.gmail.com> wrote:
> Suppose I had a really big database. Suppose it's about 1.5 TB. Now
> suppose that it's got all standard ASCII in it, with no
> internationalization, and no NCHAR or NVARCHAR fields. Now suppose it's
> currently set up with the default en_US.819 locale.
>
> Got it? Good.

Got it - it's big. You might have to buy two disk drives to fit all
the data on; four if you want to do some RAID 10 on them. More
seriously, it would take a while to unload and then load back up
again. And even with the price and size of flash drives these days,
it would take a while to back it up to 4 GB units - and you'd need a
lot of them (nearly 400 of them, I fear). Labelling might be the
biggest problem

> Now suppose a new requirement came up for internationalized data. And
> suppose we wanted to use UTF8 for this internationalization. Further,
> suppose we don't have an extra 1.5 TB laying around to do a huge migration.
>
> I understand that this is the sort of suggestion that gives IBM
> engineers nightmares, but what would be the problem with just magically
> changing some flags somewhere so that the database thinks its locale is
> en_US.UTF8 and that it has been that locale all along? Sure seems to
> beat a protracted migration, and I don't see what the problem would be,
> since there's no internationalized data right now...
>
> Thoughts? Lectures? Doomsday predictions?

If you find all the spaces and can expand the space by 1 byte (from
en_US.819 to en_US.UTF8 or whatever the CCSID number is for UTF-8),
then it might work. I'm not sure that you'd be able to approach Tech
Support with problems - as you're aware, people there justifiably do
not like dealing with systems that have been tampered with, and they
would regard that as tampering.

Doomsday predictions?

Come Doomsday, it won't matter whether the system is using UTF-8 or
8859-1; either way, it won't work afterwards.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.

Dear Tom,

Interesting problem.

On Feb 7, 2008 7:41 PM, Thomas J. Girsch <tgirsch@nospam.gmail.com> wrote:
> Suppose I had a really big database. Suppose it's about 1.5 TB. Now
> suppose that it's got all standard ASCII in it, with no
> internationalization, and no NCHAR or NVARCHAR fields. Now suppose it's
> currently set up with the default en_US.819 locale.
>
> Got it? Good.

Got it - it's big. You might have to buy two disk drives to fit all
the data on; four if you want to do some RAID 10 on them. More
seriously, it would take a while to unload and then load back up
again. And even with the price and size of flash drives these days,
it would take a while to back it up to 4 GB units - and you'd need a
lot of them (nearly 400 of them, I fear). Labelling might be the
biggest problem

> Now suppose a new requirement came up for internationalized data. And
> suppose we wanted to use UTF8 for this internationalization. Further,
> suppose we don't have an extra 1.5 TB laying around to do a huge migration.
>
> I understand that this is the sort of suggestion that gives IBM
> engineers nightmares, but what would be the problem with just magically
> changing some flags somewhere so that the database thinks its locale is
> en_US.UTF8 and that it has been that locale all along? Sure seems to
> beat a protracted migration, and I don't see what the problem would be,
> since there's no internationalized data right now...
>
> Thoughts? Lectures? Doomsday predictions?

If you find all the spaces and can expand the space by 1 byte (from
en_US.819 to en_US.UTF8 or whatever the CCSID number is for UTF-8),
then it might work. I'm not sure that you'd be able to approach Tech
Support with problems - as you're aware, people there justifiably do
not like dealing with systems that have been tampered with, and they
would regard that as tampering.

Doomsday predictions?

Come Doomsday, it won't matter whether the system is using UTF-8 or
8859-1; either way, it won't work afterwards.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
NB: Please do not use this email for correspondence.
I don't necessarily read it every week, even.

Uhh, thanks?

This might go down in the smart-alec answer hall of fame.

And if tech support doesn't like dealing with tampered-with systems,
they must LOOOOOVE Kagel!

Jonathan Leffler wrote:
> Dear Tom,
>
> Interesting problem.
>
> On Feb 7, 2008 7:41 PM, Thomas J. Girsch <tgirsch@nospam.gmail.com> wrote:
>> Suppose I had a really big database. Suppose it's about 1.5 TB. Now
>> suppose that it's got all standard ASCII in it, with no
>> internationalization, and no NCHAR or NVARCHAR fields. Now suppose it's
>> currently set up with the default en_US.819 locale.
>>
>> Got it? Good.
>
> Got it - it's big. You might have to buy two disk drives to fit all
> the data on; four if you want to do some RAID 10 on them. More
> seriously, it would take a while to unload and then load back up
> again. And even with the price and size of flash drives these days,
> it would take a while to back it up to 4 GB units - and you'd need a
> lot of them (nearly 400 of them, I fear). Labelling might be the
> biggest problem
>
>> Now suppose a new requirement came up for internationalized data. And
>> suppose we wanted to use UTF8 for this internationalization. Further,
>> suppose we don't have an extra 1.5 TB laying around to do a huge migration.
>>
>> I understand that this is the sort of suggestion that gives IBM
>> engineers nightmares, but what would be the problem with just magically
>> changing some flags somewhere so that the database thinks its locale is
>> en_US.UTF8 and that it has been that locale all along? Sure seems to
>> beat a protracted migration, and I don't see what the problem would be,
>> since there's no internationalized data right now...
>>
>> Thoughts? Lectures? Doomsday predictions?
>
> If you find all the spaces and can expand the space by 1 byte (from
> en_US.819 to en_US.UTF8 or whatever the CCSID number is for UTF-8),
> then it might work. I'm not sure that you'd be able to approach Tech
> Support with problems - as you're aware, people there justifiably do
> not like dealing with systems that have been tampered with, and they
> would regard that as tampering.
>
> Doomsday predictions?
>
> Come Doomsday, it won't matter whether the system is using UTF-8 or
> 8859-1; either way, it won't work afterwards.
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
> NB: Please do not use this email for correspondence.
> I don't necessarily read it every week, even.

Uhh, thanks?

This might go down in the smart-alec answer hall of fame.

And if tech support doesn't like dealing with tampered-with systems,
they must LOOOOOVE Kagel!

Jonathan Leffler wrote:
> Dear Tom,
>
> Interesting problem.
>
> On Feb 7, 2008 7:41 PM, Thomas J. Girsch <tgirsch@nospam.gmail.com> wrote:
>> Suppose I had a really big database. Suppose it's about 1.5 TB. Now
>> suppose that it's got all standard ASCII in it, with no
>> internationalization, and no NCHAR or NVARCHAR fields. Now suppose it's
>> currently set up with the default en_US.819 locale.
>>
>> Got it? Good.
>
> Got it - it's big. You might have to buy two disk drives to fit all
> the data on; four if you want to do some RAID 10 on them. More
> seriously, it would take a while to unload and then load back up
> again. And even with the price and size of flash drives these days,
> it would take a while to back it up to 4 GB units - and you'd need a
> lot of them (nearly 400 of them, I fear). Labelling might be the
> biggest problem
>
>> Now suppose a new requirement came up for internationalized data. And
>> suppose we wanted to use UTF8 for this internationalization. Further,
>> suppose we don't have an extra 1.5 TB laying around to do a huge migration.
>>
>> I understand that this is the sort of suggestion that gives IBM
>> engineers nightmares, but what would be the problem with just magically
>> changing some flags somewhere so that the database thinks its locale is
>> en_US.UTF8 and that it has been that locale all along? Sure seems to
>> beat a protracted migration, and I don't see what the problem would be,
>> since there's no internationalized data right now...
>>
>> Thoughts? Lectures? Doomsday predictions?
>
> If you find all the spaces and can expand the space by 1 byte (from
> en_US.819 to en_US.UTF8 or whatever the CCSID number is for UTF-8),
> then it might work. I'm not sure that you'd be able to approach Tech
> Support with problems - as you're aware, people there justifiably do
> not like dealing with systems that have been tampered with, and they
> would regard that as tampering.
>
> Doomsday predictions?
>
> Come Doomsday, it won't matter whether the system is using UTF-8 or
> 8859-1; either way, it won't work afterwards.
>
> --
> Jonathan Leffler #include <disclaimer.h>
> Email: jleffler@earthlink.net, jleffler@us.ibm.com
> Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/
> NB: Please do not use this email for correspondence.
> I don't necessarily read it every week, even.

Thomas J. Girsch wrote:
> Uhh, thanks?
>
> This might go down in the smart-alec answer hall of fame.
>
> And if tech support doesn't like dealing with tampered-with systems,
> they must LOOOOOVE Kagel!
>

Don't get me involved in this, Thomas. I ONLY muck around when there's
no other choice! 8-(

Seriously, I'm usually the first to say: Don't mess with the system
tables! I'll only touch things that are known to be safe to touch. I
only muck in the guts to rescue a doomed system's data - and then I want
to export everything that's salvageable and rebuild from scratch.

Art S. Kagel
Oninit


================================================== =========================================
Please access the attached hyperlink for an important electronic communications disclaimer:

http://www.oninit.com/home/disclaimer.php

================================================== =========================================

Yes, but in this case you can't do any sort of hack.
(Think about what you're asking ;-)

My suggestion would be to first consider if you are in a position to upgrade your existing hardware.

If not, then lease new hardware for month(s) or a year, migrate your data to your new system where you will have international character sets, and then migrate back.

Of course you'll need to increase your disk space...


> Date: Tue, 12 Feb 2008 10:58:20 -0500
> From: art@oninit.com
> To: tgirsch@gmail.com
> Subject: Re: A hypothetical hack
> CC: informix-list@iiug.org
>
> Thomas J. Girsch wrote:
> > Uhh, thanks?
> >
> > This might go down in the smart-alec answer hall of fame.
> >
> > And if tech support doesn't like dealing with tampered-with systems,
> > they must LOOOOOVE Kagel!
> >
>
> Don't get me involved in this, Thomas. I ONLY muck around when there's
> no other choice! 8-(
>
> Seriously, I'm usually the first to say: Don't mess with the system
> tables! I'll only touch things that are known to be safe to touch. I
> only muck in the guts to rescue a doomed system's data - and then I want
> to export everything that's salvageable and rebuild from scratch.
>
> Art S. Kagel
> Oninit
>
>
> ================================================== =========================================
> Please access the attached hyperlink for an important electronic communications disclaimer:
>
> http://www.oninit.com/home/disclaimer.php
>
> ================================================== =========================================
>
> _______________________________________________
> Informix-list mailing list
> Informix-list@iiug.org
> http://www.iiug.org/mailman/listinfo/informix-list

__________________________________________________ _______________
Helping your favorite cause is as easy as instant messaging.*You IM, we give.
http://im.live.com/Messenger/IM/Home...t_hotmail_join

Thomas J. Girsch wrote:
> Uhh, thanks?
>
> This might go down in the smart-alec answer hall of fame.

OK - fair enough. I did wonder whether I should hit send; evidently,
the liquid consumed prior to hitting 'send' didn't improve my judgement.

I'll see what else can be done off-line.

--
Jonathan Leffler #include <disclaimer.h>
Email: jleffler@earthlink.net, jleffler@us.ibm.com
Guardian of DBD::Informix v2007.0914 -- http://dbi.perl.org/

publictimestamp.org/ptb/PTB-2509 whirlpool0 2008-02-13 03:00:05
AE88A543AB8797E6B4A2E0B7D9AF91446A25A962A4888BD729 0CFAEF15F12D560BEC38
A98B51139E183211539245C9919CD3C8BD953DEE4C3614B8D8 4CE63FB

Oh, don't get me wrong, I laughed. And after the grief I've given you
over the years, I probably had it coming. One of my first thoughts was
"this is what I get for nagging him about getting ISQL forms to work
with fragmented tables every time I see him..."

Speaking of which...

Jonathan Leffler wrote:
> Thomas J. Girsch wrote:
>> Uhh, thanks?
>>
>> This might go down in the smart-alec answer hall of fame.
>
> OK - fair enough. I did wonder whether I should hit send; evidently,
> the liquid consumed prior to hitting 'send' didn't improve my judgement.
>
> I'll see what else can be done off-line.
>