Update ICU to 4.2.1

[Adriano dos Santos Fernandes-3]

All,

We talked about update ICU many times and regret. Main reason has that they generated keys differs from version to version, so we would need to have at least different binary versions for different ODSs. Code two support different binaries is there since 2.1.

Now we even talk about support only ODS 12 in FB 3, so this impact is gone.

So, is it the time to update it? I could do it for Windows and Linux and others platforms may need some changes as previously.

Also, should we continue to customize it to reduce some MB? IMHO, this is not necessary in these days, and anyone that care may do it directly. Maybe I should just update it and we see later how many MB it uses and decide?

Apparently, now they generate its files separated for 32/64 bit in Windows. But they dropped MSVC8 projects, so we'll need to convert from MSVC9.


Adriano


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Vlad Khorsun-2]

> We talked about update ICU many times and regret. Main reason has that they generated keys differs from version to version, so we
> would need to have at least different binary versions for different ODSs. Code two support different binaries is there since 2.1.
>
> Now we even talk about support only ODS 12 in FB 3, so this impact is gone.
>
> So, is it the time to update it? I could do it for Windows and Linux and others platforms may need some changes as previously.

    If we really decide to drop support for < ODS 12, i vote for it.

> Also, should we continue to customize it to reduce some MB? IMHO, this is not necessary in these days, and anyone that care may do
> it directly. Maybe I should just update it and we see later how many MB it uses and decide?

    I would like to see the difference.

> Apparently, now they generate its files separated for 32/64 bit in Windows. But they dropped MSVC8 projects, so we'll need to
> convert from MSVC9.

    I hope we will release FB3 with MSVC10 as official compiler ;)

Regards,
Vlad


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Dmitry Yemanov]

Vlad Khorsun wrote:

> If we really decide to drop support for < ODS 12, i vote for it.

Seconded.


Dmitry

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Monday 02 November 2009 18:31:50 Adriano dos Santos Fernandes wrote:
> All,
>
> We talked about update ICU many times and regret. Main reason has that they
> generated keys differs from version to version, so we would need to have at
> least different binary versions for different ODSs. Code two support
> different binaries is there since 2.1.
>
> Now we even talk about support only ODS 12 in FB 3, so this impact is gone.

May we take a bit wider look at this problem?
As soon as we
- got a code to support different ODS versions
- do not plan to support ODS11 in FB3

Why do we need at all ICU in our tree? We must drop it and let people use
version which they need. IMO there will be some ICU version in windows
binaries, but for posix - what need in it at all?

Next. If we anyway perform dynamic load of ICU libraries, why should our
binaries depend on it and perform load of ICU libraries when they are
started?

Alex.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Adriano dos Santos Fernandes-3]

Alexander Peshkoff wrote:

> On Monday 02 November 2009 18:31:50 Adriano dos Santos Fernandes wrote:
>> All,
>>
>> We talked about update ICU many times and regret. Main reason has that they
>> generated keys differs from version to version, so we would need to have at
>> least different binary versions for different ODSs. Code two support
>> different binaries is there since 2.1.
>>
>> Now we even talk about support only ODS 12 in FB 3, so this impact is gone.
>
> May we take a bit wider look at this problem?
> As soon as we
> - got a code to support different ODS versions
> - do not plan to support ODS11 in FB3
>
> Why do we need at all ICU in our tree?

We have even tools (btyacc) in out tree, Alex. So it seems we want a build we do not depend on others downloads.

> We must drop it and let people use
> version which they need.

And will create incompatibilities to move just database of same ODS between different installs.

> IMO there will be some ICU version in windows
> binaries, but for posix - what need in it at all?
>
Same reason as above.

> Next. If we anyway perform dynamic load of ICU libraries, why should our
> binaries depend on it and perform load of ICU libraries when they are
> started?
>
Core charset functions depends on it, so it's not optional as collations. May be loaded dynamically, yes, but solves nothing per se.


Adriano


------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Philippe Makowski]

2009/11/2 Adriano dos Santos Fernandes <adrianosf@...>:
>> We must drop it and let people use
>> version which they need.
>
> And will create incompatibilities to move just database of same ODS between different installs.
not if you backup / restore them
or even only rebuild indices

or did I miss something ?

every distro packages (Mandriva, Fedora, OpenSuse, Debian) use ICU
from the distro, not the one from our tree

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Dmitry Yemanov]

Philippe Makowski wrote:
>
>> And will create incompatibilities to move just database of same ODS between different installs.

> not if you backup / restore them
> or even only rebuild indices
>
> or did I miss something ?
>
> every distro packages (Mandriva, Fedora, OpenSuse, Debian) use ICU
> from the distro, not the one from our tree

Speaking honestly, this somewhat defeats the idea behind ODS. Databases
of the same major ODS version are expected to be portable between boxes
with the same architecture (alignment / endianness). It's really sad
that the ICU stuff breaks this rule.


Dmitry

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Monday 02 November 2009 20:17:35 Adriano dos Santos Fernandes wrote:

> Alexander Peshkoff wrote:
> > On Monday 02 November 2009 18:31:50 Adriano dos Santos Fernandes wrote:
> >> All,
> >>
> >> We talked about update ICU many times and regret. Main reason has that
> >> they generated keys differs from version to version, so we would need to
> >> have at least different binary versions for different ODSs. Code two
> >> support different binaries is there since 2.1.
> >>
> >> Now we even talk about support only ODS 12 in FB 3, so this impact is
> >> gone.
> >
> > May we take a bit wider look at this problem?
> > As soon as we
> > - got a code to support different ODS versions
> > - do not plan to support ODS11 in FB3
> >
> > Why do we need at all ICU in our tree?
>
> We have even tools (btyacc) in out tree, Alex. So it seems we want a build
> we do not depend on others downloads.

If we follow thsi logic, we must include gcc in it - some versions of it can't
build FB correctly:)

Getting serious - btyacc is almost unsupported product, and if I do not miss
soemthing, Nickolay had to do some changes to it to make it work for us.
Almost same applies to editline - I've made fixes in it to make Delete key
work as expected, sent changes to developers, but had no reply on it. I.e.
for this both products we can't use standard versions.

On contrary, we have a lot of problems cause we need to use old, buggy, not MT
safe (works for us only due to presence of unrelated locks in our code)
version of ICU. And if now we import freshest sources, we will for sure have
more or less same problems in 2 or 3 years.

> > We must drop it and let people use
> > version which they need.
>
> And will create incompatibilities to move just database of same ODS between
> different installs.

I'm afraid we can't avoid this. Project does not have enough resources to
provide high-quality support for so many international charsets - nor by
supporting particular version of ICU (what we have in 2.X is bad support),
nor by builing own layer.

If we document this for ODS12 (and may be adding isc_dpb_indices_rebuild in
gfix), this will be better than what we have in 2.X, specially taking into an
account that....

> Philippe Makowski wrote:
> > every distro packages (Mandriva, Fedora, OpenSuse, Debian) use ICU
> > from the distro, not the one from our tree
>
> Speaking honestly, this somewhat defeats the idea behind ODS. Databases
> of the same major ODS version are expected to be portable between boxes
> with the same architecture (alignment / endianness). It's really sad
> that the ICU stuff breaks this rule.

But distros do not accept packages that attempt to use ancient version of ICU,
known to have security, MT, etc. problems. The fact that we forcibly insert
such version in our binary packages does not mean we are doing something
good.

> > Next. If we anyway perform dynamic load of ICU libraries, why should our
> > binaries depend on it and perform load of ICU libraries when they are
> > started?
>
> Core charset functions depends on it, so it's not optional as collations.
> May be loaded dynamically, yes, but solves nothing per se.

This agreed - missed the point. The only reason to load them dynamically is to
avoid distributing ICU in light-weight embedded systems, where it's not
needed at all.

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Bill Oliver-2]

For my purposes, version of ICU in tree was too old, so I
use --with-system-icu for my HPUX, Solaris, AIX builds. Moving to new
version of ICU is good thing for 3.0.

On Linux, if ICU were removed from the Firebird tree, can we make the
Firebird package dependent upon a certain version of ICU being installed?

Then, if you install Firebird via RPM, the ICU package could be
automatically installed too, as a dependency?

Is that right? That seems to be desirable, but there may be things I miss.
The Windows side is completely different, and Windows users are not
accustomed to a 2-step install, ICU first, then Firebird. Seems Windows
users would want a 1-step installation, which implies including ICU in tree.

-b

"Alexander Peshkoff" <peshkoff@...> wrote in message
news:200911031123.07750.peshkoff@......

> On Monday 02 November 2009 20:17:35 Adriano dos Santos Fernandes wrote:
>> Alexander Peshkoff wrote:
>> > On Monday 02 November 2009 18:31:50 Adriano dos Santos Fernandes wrote:
>> >> All,
>> >>
>> >> We talked about update ICU many times and regret. Main reason has that
>> >> they generated keys differs from version to version, so we would need
>> >> to
>> >> have at least different binary versions for different ODSs. Code two
>> >> support different binaries is there since 2.1.
>> >>
>> >> Now we even talk about support only ODS 12 in FB 3, so this impact is
>> >> gone.
>> >
>> > May we take a bit wider look at this problem?
>> > As soon as we
>> > - got a code to support different ODS versions
>> > - do not plan to support ODS11 in FB3
>> >
>> > Why do we need at all ICU in our tree?
>>
>> We have even tools (btyacc) in out tree, Alex. So it seems we want a
>> build
>> we do not depend on others downloads.
>
> If we follow thsi logic, we must include gcc in it - some versions of it
> can't
> build FB correctly:)
>
> Getting serious - btyacc is almost unsupported product, and if I do not
> miss
> soemthing, Nickolay had to do some changes to it to make it work for us.
> Almost same applies to editline - I've made fixes in it to make Delete key
> work as expected, sent changes to developers, but had no reply on it. I.e.
> for this both products we can't use standard versions.
>
> On contrary, we have a lot of problems cause we need to use old, buggy,
> not MT
> safe (works for us only due to presence of unrelated locks in our code)
> version of ICU. And if now we import freshest sources, we will for sure
> have
> more or less same problems in 2 or 3 years.
>
>> > We must drop it and let people use
>> > version which they need.
>>
>> And will create incompatibilities to move just database of same ODS
>> between
>> different installs.
>
> I'm afraid we can't avoid this. Project does not have enough resources to
> provide high-quality support for so many international charsets - nor by
> supporting particular version of ICU (what we have in 2.X is bad support),
> nor by builing own layer.
>
> If we document this for ODS12 (and may be adding isc_dpb_indices_rebuild
> in
> gfix), this will be better than what we have in 2.X, specially taking into
> an
> account that....
>
>> Philippe Makowski wrote:
>> > every distro packages (Mandriva, Fedora, OpenSuse, Debian) use ICU
>> > from the distro, not the one from our tree
>>
>> Speaking honestly, this somewhat defeats the idea behind ODS. Databases
>> of the same major ODS version are expected to be portable between boxes
>> with the same architecture (alignment / endianness). It's really sad
>> that the ICU stuff breaks this rule.
>
> But distros do not accept packages that attempt to use ancient version of
> ICU,
> known to have security, MT, etc. problems. The fact that we forcibly
> insert
> such version in our binary packages does not mean we are doing something
> good.
>
>> > Next. If we anyway perform dynamic load of ICU libraries, why should
>> > our
>> > binaries depend on it and perform load of ICU libraries when they are
>> > started?
>>
>> Core charset functions depends on it, so it's not optional as collations.
>> May be loaded dynamically, yes, but solves nothing per se.
>
> This agreed - missed the point. The only reason to load them dynamically
> is to
> avoid distributing ICU in light-weight embedded systems, where it's not
> needed at all.
>
> ------------------------------------------------------------------------------
> Come build with us! The BlackBerry(R) Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9 - 12, 2009. Register now!
> http://p.sf.net/sfu/devconference
> Firebird-Devel mailing list, web interface at
> https://lists.sourceforge.net/lists/listinfo/firebird-devel
>

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Paul Reeves-2]

On Tuesday 03 November 2009, Bill Oliver wrote:
> The Windows side is completely different, and Windows users are not
> accustomed to a 2-step install, ICU first, then Firebird. Seems Windows
> users would want a 1-step installation, which implies including ICU in
> tree.

Well, the innosetup installer can be set up to install other packages. It is
common enough, although not an everyday occurrence.

And, of course, Firebird since 2.1 silently installs the MSVCRT libraries as
an assembly. They are compiled into an .msi package with wix.

I think the assembly approach might be more appropriate for ICU. However, we
lose control of which assembly is used. The O/S seems to choose the newest.


Paul
--
Paul Reeves
http://www.ibphoenix.com
Specialists in Firebird support

------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Tuesday 03 November 2009 17:42:28 Bill Oliver wrote:
> For my purposes, version of ICU in tree was too old, so I
> use --with-system-icu for my HPUX, Solaris, AIX builds. Moving to new
> version of ICU is good thing for 3.0.
>
> On Linux, if ICU were removed from the Firebird tree, can we make the
> Firebird package dependent upon a certain version of ICU being installed?

I think for RPM it's possible, though I'm not RPM expert.

> Then, if you install Firebird via RPM, the ICU package could be
> automatically installed too, as a dependency?
>
> Is that right? That seems to be desirable, but there may be things I miss.
> The Windows side is completely different, and Windows users are not
> accustomed to a 2-step install, ICU first, then Firebird. Seems Windows
> users would want a 1-step installation, which implies including ICU in
> tree.

Bill, the primary problem (as seen by me) is not installer issues. I'm sure
that any linux distro has tools to have required libraries installed. Adding
some version of ICU to windows installer is also not a problem. Moreover, I'm
sure that SAS too can easily force presence of appropriate ICU version on
clients' machines.

The problem is that before we added --with-system-icu switch and ability to
work with multiple ICU versions (one database can use version X, another -
version Y), databases were binary compatible between different firebird
installations. Currently one can create database at machine A with some ICU
version, but after copying to machine B, missing exactly that ICU version,
database becomes unreadable, provided it's using indices on non-ascii
strings. Should notice, that ability to copy databases as files across
machines is not required for SQL-servers feature. Once many years ago I've
needed to restore MSSQL database (clients did not have fresh backup) when
windows became unbootable. Well - after installing exactly same set of
windows and mssql server service packs (luckily automatic windows updates did
not exist that time), restoring parts of registry and master database from
crashed system, I've succeeded to do it. But normally such operations are not
supported - people must use backups.

For firebird when mismatch of ICU takes place, users always have the simplest
solution if database is very big - install required ICU. As a measure to
avoid full backup/restore cycle we can easily provide index regenaration in
gfix - this can be specially efficient because we may recreate only indices
with non-ascii strings.

Alex.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Michael Weissenbacher-2]

Hi!
>> On Linux, if ICU were removed from the Firebird tree, can we make the
>> Firebird package dependent upon a certain version of ICU being installed?
>
> I think for RPM it's possible, though I'm not RPM expert.
>
Possible for .RPM, .DEB and also on Gentoo!

> crashed system, I've succeeded to do it. But normally such operations are not
> supported - people must use backups.
>
I think it should be common practice to always to a backup/restore cycle when moving DB from one system to another. But that's just my humble opinion.

> As a measure to
> avoid full backup/restore cycle we can easily provide index regenaration in
> gfix - this can be specially efficient because we may recreate only indices
> with non-ascii strings.
I think this would be a really cool feature and could save some time, especially on big databases!

I think in practice different ICU versions on the same ODS version are already a non-problem because all the major distros i know of (Ubuntu, Debian, Gentoo, etc) have been using external ICU for years and people should already have become aware that a backup/restore is necessary in case of an ICU library change.

with regards,
Michael

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Wednesday 04 November 2009 12:52:14 Michael Weissenbacher wrote:

> Hi!
>
> >> On Linux, if ICU were removed from the Firebird tree, can we make the
> >> Firebird package dependent upon a certain version of ICU being
> >> installed?
> >
> > I think for RPM it's possible, though I'm not RPM expert.
>
> Possible for .RPM, .DEB and also on Gentoo!
>
> > crashed system, I've succeeded to do it. But normally such operations are
> > not supported - people must use backups.
>
> I think it should be common practice to always to a backup/restore cycle
> when moving DB from one system to another. But that's just my humble
> opinion.

Sometimes you need to quickly(!) recover a database after server crash on
another server. Ability to copy databases as files (from old HDD to new one
in my sample) is very cool here.

> > As a measure to
> > avoid full backup/restore cycle we can easily provide index regenaration
> > in gfix - this can be specially efficient because we may recreate only
> > indices with non-ascii strings.
>
> I think this would be a really cool feature and could save some time,
> especially on big databases!
>
> I think in practice different ICU versions on the same ODS version are
> already a non-problem because all the major distros i know of (Ubuntu,
> Debian, Gentoo, etc) have been using external ICU for years and people
> should already have become aware that a backup/restore is necessary in case
> of an ICU library change.

Main problem is huge pool of windows users. Also do not forget that many
people use SF binaries, which contained same version of ICU. But generally
you are certainly right - having same ODS version with different ICU version
is not so bad to make us use ancient ICU.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Dimitry Sibiryakov-3]

> Sometimes you need to quickly(!) recover a database after server crash on
> another server. Ability to copy databases as files (from old HDD to new one
> in my sample) is very cool here.

   In this case copying is done between the same versions of OSes with
the same versions of components, including ICU, so copy must be OK.
   What to quick recovery as such, IIRC Vlad was going to implement
built-in replication which is perfect for such purpose.

   SY, SD.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Vlad Khorsun-2]

    Just a note

>   What to quick recovery as such, IIRC Vlad was going to implement
> built-in replication which is perfect for such purpose.

    I never said about built-in replication. I just joke one time that i going
to leave you without a job ;) Quick recovery could be reached without
replication. Replication is not an "our all" :)

Regards,
Vlad

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Milan Babuskov]

Alexander Peshkoff wrote:
> For firebird when mismatch of ICU takes place, users always have the simplest
> solution if database is very big - install required ICU.

It is not "simplest", it is even not "simple". Firebird is not the only
software using ICU, and other software might require different versions
to work properly.

OTOH, sorry for being completely ignorant about ICU internals, but I
don't get this whole issue with keys. I mean: UTF-8 is UTF-8. If FB
stores it as UTF-8, what have the keys got to do with anything? Why are
those keys needed at all? What's their purpose?

Thanks,

--
Milan Babuskov

==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Milan Babuskov]

Philippe Makowski wrote:
> 2009/11/2 Adriano dos Santos Fernandes <adrianosf@...>:
>>> We must drop it and let people use
>>> version which they need.
>> And will create incompatibilities to move just database of same ODS between different installs.
> not if you backup / restore them

Would nbackup also work in this case?

--
Milan Babuskov

==================================
The easiest way to import XML, CSV
and textual files into Firebird:
http://www.guacosoft.com/xmlwizard
==================================


------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Ann W. Harrison]

Milan Babuskov wrote:
...
>>> And will create incompatibilities to move just database of same ODS between different installs.
>> not if you backup / restore them
>
> Would nbackup also work in this case?
>

No.  Gbak is a logical backup which copies metadata and data to recreate
the database including indexes.  Nbackup is a physical backup of the
file including all structures - in this case, specifically including
the indexes as they were created on the original host.


Ann

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Wednesday 04 November 2009 21:52:36 Milan Babuskov wrote:
> Alexander Peshkoff wrote:
> > For firebird when mismatch of ICU takes place, users always have the
> > simplest solution if database is very big - install required ICU.
>
> It is not "simplest", it is even not "simple". Firebird is not the only
> software using ICU, and other software might require different versions
> to work properly.

It is very simple. Various ICU versions may coexist on the same box. It's true
not only for linux (on linux it's normal that libraries with different
sonames coexist), but for windows too, because soname is part of filename on
windows version of ICU.

> OTOH, sorry for being completely ignorant about ICU internals, but I
> don't get this whole issue with keys. I mean: UTF-8 is UTF-8. If FB
> stores it as UTF-8, what have the keys got to do with anything? Why are
> those keys needed at all? What's their purpose?

Keys is the compact representation of characters for sorting. It's documented
that keys for same sequence of characters may vary when ICU version is
changed. Therefore index, build using some ICU version, may become useless
with another version - keys contained in index may differ from one engine
tries to search for.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel

[Alexander Peshkoff]

On Wednesday 04 November 2009 15:01:54 Dimitry Sibiryakov wrote:
> > Sometimes you need to quickly(!) recover a database after server crash on
> > another server. Ability to copy databases as files (from old HDD to new
> > one in my sample) is very cool here.
>
>    In this case copying is done between the same versions of OSes with
> the same versions of components, including ICU, so copy must be OK.

Ideally yes, but shit happens.

------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel