Jim Nasby wrote:
On Jun 21, 2006, at 7:42 AM, H.J. Sanders wrote:
The last 15 years we also used Informix and we never, never had to
unload/load
the database because of an upgrade.
Perhaps somebody knows how they do the trick?
Do they provide a migration/upgrade utility?
In the case of
On Jun 21, 2006, at 7:42 AM, H.J. Sanders wrote:
The last 15 years we also used Informix and we never, never had to
unload/load
the database because of an upgrade.
Perhaps somebody knows how they do the trick?
Do they provide a migration/upgrade utility?
--
Jim C. Nasby, Sr. Engineering Cons
>>>
> >>> Is anybody over at the dev team considering what an onerous burden
> >>> this is? Is anyone considering doing away with it?
Just my 2 cents:
more and more databases have to run 24 * 7 , so something has to be done.
The last 15 years we also used Informix and we never, never had to
Kenneth Downs wrote:
Richard Huxton wrote:
Kenneth Downs wrote:
AFAIK it has always been the case that you should expect to have to
dump out your databases and reload them for version upgrades.
Is anybody over at the dev team considering what an onerous burden
this is? Is anyone consideri
On Wed, Jun 21, 2006 at 08:10:20AM -0400, Kenneth Downs wrote:
> Regardless of whether a package is commercial or free, it strikes me as
> counter to the very soul of programming to build in a burden that
> increases with the user's use of the program, threatening even to tip
> the balance altog
Richard Huxton wrote:
Kenneth Downs wrote:
AFAIK it has always been the case that you should expect to have to
dump out your databases and reload them for version upgrades.
Is anybody over at the dev team considering what an onerous burden
this is? Is anyone considering doing away with it?
In response to snacktime <[EMAIL PROTECTED]>:
> On 6/16/06, Richard Huxton wrote:
>
> > The other option would be to run replication, e.g. slony to migrate from
> > one version to another. I've done it and it works fine, but it will mean
> > slony adding its own tables to each database. I'd stil
On 6/16/06, Richard Huxton wrote:
The other option would be to run replication, e.g. slony to migrate from
one version to another. I've done it and it works fine, but it will mean
slony adding its own tables to each database. I'd still do it one
merchant at a time, but that should reduce your d
Kenneth Downs wrote:
AFAIK it has always been the case that you should expect to have to dump
out your databases and reload them for version upgrades.
Is anybody over at the dev team considering what an onerous burden this
is? Is anyone considering doing away with it?
Far from trivial. You
On Thu, 15 Jun 2006, snacktime wrote:
Anyone have any tips for minimizing downtime when upgrading? So far
we have done upgrades during scheduled downtimes. Now we are getting
to the point where the time required for a standard dump/restore is
just too long. What have others done when downtime
snacktime wrote:
Anyone have any tips for minimizing downtime when upgrading? So far
we have done upgrades during scheduled downtimes. Now we are getting
to the point where the time required for a standard dump/restore is
just too long. What have others done when downtime is critical? The
on
snacktime wrote:
Anyone have any tips for minimizing downtime when upgrading? So far
we have done upgrades during scheduled downtimes. Now we are getting
to the point where the time required for a standard dump/restore is
just too long. What have others done when downtime is critical? The
onl
12 matches
Mail list logo
