Roy,

<< I was going to wait until you'd caught up with your sleep but you had to
go and wake up early. >>

Yeah, occasionally I do get up at a reasonable time.

<< Restore from backup, just extract one table (sav 150k records, 1.3Gb inc
blobs) c30mins Vs "You would have to restore the catalog also, into a new
database for this purpose if you don't want to overwrite the existing
database catalog, and then move the table data over using an INSERT
statement."

No idea how long (don't even know how yet, I'll have to play in EDBMan to
see about transferring data between databases) >>

Yes, but in what circumstances would this be required ?  How many database
restores need to occur on tables that have a different structure from the
backup ?  IOW, restores are a method of disaster recovery in 95% of the
cases, which means that, in the case that is being presented here:

a) The database wasn't backed up on a daily basis like it should be, or
b) The user/developer was trying to restore a table after an alteration that
went badly, in which case they only need to restore the .Old versions of the
catalog and table(s) in order to get back to working order

a) is going to result in problems no matter what we do, and b) is a
no-brainer for the developer.

I think we're debating a non-issue that will very rarely occur, and when it
does it will most likely be caused by a).

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

>a) The database wasn't backed up on a daily basis like it should be, or

Yes and so we punish the user rather than help?

>b) The user/developer was trying to restore a table after an alteration that
>went badly, in which case they only need to restore the .Old versions of the
>catalog and table(s) in order to get back to working order
>
>a) is going to result in problems no matter what we do, and b) is a
>no-brainer for the developer.
>
>I think we're debating a non-issue that will very rarely occur, and when it
>does it will most likely be caused by a).

I beg to differ. Its basically gut feeling at the moment. We'll see what happens as ElevateDB goes into real life apps. I know whichever of us is wrong will gracefully concede defeat. In my case with a pleasant "you were right and I was wrong" and in your case with a hell of a lot of work <c>.

Roy Lambert

Roy,

<< Yes and so we punish the user rather than help? >>

No one is trying to punish anyone.  If you don't have insurance on your
house and it burns to the ground, no one is punishing you.  You simply
screwed up and a bad thing happened.  EDB's architecture requires that you
back up databases (with the catalog) on a regular basis if you want proper
disaster recovery in the case of needing to recover a table.  If you don't
backup on a regular basis, then restoring a very old backup with a different
catalog/table structure will be a PIA.

<< I beg to differ. Its basically gut feeling at the moment. We'll see what
happens as ElevateDB goes into real life apps. I know whichever of us is
wrong will gracefully concede defeat. In my case with a pleasant "you were
right and I was wrong" and in your case with a hell of a lot of work <c>. >>

Beg to differ how ?  Can you think of another cause that I did not describe
that would result in the situation that has been described by Chris ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


> will very rarely occur

That's the bit I differ on

Roy Lambert

Roy,

<< will very rarely occur

That's the bit I differ on >>

Really ?  How often do you think table alteration will occur at a customer's
site without a backup within a reasonable amount of time ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I know a lot of people who have NEVER taken a backup. As a hobbyist I support a massive 5 sites and 3 of them, no matter how much I badger, have never backed a thing up. I issue at least 1 and sometimes 2 upgrades a year involving a table structure change (generally fairly trivial). I don't know how that relates to others out there. Memory says I've had to cope with at least one table corruption issue a year.


My favourite non-backer-upper is a guy called Allan. Totally ignored all suggestions to back up. Kept phoning me with corrupt table issues which I kept on fixing somehow. He was told it was a duff disk. After 3.5 - 4 years the disk packed up. I ended up having to "restore" his data from the conversion I'd done 3.5 - 4 years back when I last did a major upgrade and which I could fortunately find the CD I'd burnt back then.

Roy Lambert

Roy,

<< I know a lot of people who have NEVER taken a backup. As a hobbyist I
support a massive 5 sites and 3 of them, no matter how much I badger, have
never backed a thing up. I issue at least 1 and sometimes 2 upgrades a year
involving a table structure change (generally fairly trivial). I don't know
how that relates to others out there. Memory says I've had to cope with at
least one table corruption issue a year. >>

Sure, but that still doesn't fit the scenario described, i.e. a situation
where a backup needs to restore a single table whose structure is different
from that in the current catalog.  IOW, if someone *does* do backups, then
there is a good chance that there will be a backup within a reasonable
amount of time after an alteration.  If there isn't any backups at all, then
tough luck, but you'll have to suffice with whatever a repair can recover.

<< My favourite non-backer-upper is a guy called Allan. Totally ignored all
suggestions to back up. Kept phoning me with corrupt table issues which I
kept on fixing somehow. He was told it was a duff disk. After 3.5 - 4 years
the disk packed up. I ended up having to "restore" his data from the
conversion I'd done 3.5 - 4 years back when I last did a major upgrade and
which I could fortunately find the CD I'd burnt back then. >>

Again, disk failures also wouldn't fit the scenario described.  In the
scenario here, you would restore the database that you had from several
years back and have to move it forward through any or all alterations.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I think I'll withdraw gracefully from this discussion until I (or someone) have some stats or a few years have gone by and proven me wrong. After all your time can be better spent slaving over the documentation

Roy Lambert

Roy,

<< I think I'll withdraw gracefully from this discussion until I (or
someone) have some stats or a few years have gone by and proven me wrong.
After all your time can be better spent slaving over the documentation
>>

Sorry, I wasn't trying to goad you into responding.  I was just trying to
make sure that you didn't have a scenario in your head that I was completely
missing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


Don't worry, you didn't. I realised I can't explain what I'm on about any better. There is still a nagging feeling in there but if I can't put it into words all we do is waste each others time. A criminal act when you could be checking out my table creation problem in DBISAM

Roy Lambert