With EDBMgr, I can backup a database. This produces a EDB.bkp file.
Now I want to copy this to another computer and restore this there.

How can I do that?
EDBMgr seems to expect that the backup had been done with the same EDBCfg file. It SQLs on
the Backup system table? Of course this backup is not logged there and the list will
remain empty.

I have looked around in the docs and there seems to be no solution for my requirement?
This is a basic method of exchanging data!
How would you be able to restore a backup on a new computer after a crash?

Please help
Stephan Krämer

Stephan,

<< How can I do that?  EDBMgr seems to expect that the backup had been done
with the same EDBCfg file. It SQLs on the Backup system table? Of course
this backup is not logged there and the list will remain empty. >>

See here:

http://www.elevatesoft.com/edb_faqt_2.htm

The same applies for this situation, except that you don't DROP the database
on the new computer because it doesn't exist yet.  Just use the CREATE
DATABASE statement to create the database on the new computer, and then
restore the backup into that database using the RESTORE DATABASE statement.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

>>http://www.elevatesoft.com/edb_faqt_2.htm

This does not match my situation.

>>
The same applies for this situation, except that you don't DROP the database
on the new computer because it doesn't exist yet.  Just use the CREATE
DATABASE statement to create the database on the new computer, and then
restore the backup into that database using the RESTORE DATABASE statement.
<<

I think the reason why I did not see the backups in the list, was different signature and
encryption?

I retried the whole thing without any signature and encryption.

I backup the database A in EDBMgr.

In EDBMgr, I create database B and want to restore the backup of A into that one. ->
Result Error: Division by zero.
If I try to restore into the same database A, then I get ElevateDB Error #400 The table
already exists.

I had always included the catalog. BTW: Why is the catalog not checked by default with the
restore?


Stephan Krämer

Stephan,

<< This does not match my situation. >>

Which is why I wrote:

"The same applies for this situation, except....."

<< I think the reason why I did not see the backups in the list, was
different signature and encryption? >>

If the signature and/or encryption was different, then yes, that would cause
the backup(s) to not show up in the EDB Manager.

<< I retried the whole thing without any signature and encryption.

I backup the database A in EDBMgr.

In EDBMgr, I create database B and want to restore the backup of A into
that one. ->

Result Error: Division by zero. >>

Can you send me the backup that you're using ?

<< If I try to restore into the same database A, then I get ElevateDB Error
#400 The table already exists. >>

It sounds like a possible issue with restoring the catalog.  I will see what
I can find out.

<< I had always included the catalog. BTW: Why is the catalog not checked by
default with the restore? >>

Because during normal operation the catalog will change rarely, whereas the
data itself will change regularly.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

Can you send me the backup that you're using ?

Yes, I did so by email.

Stephan Krämer

Stephan,

<< Yes, I did so by email. >>

Did you create this backup using 1.04 ?  If so, then it appears to be an
issue with the backup functionality and older catalog versions when using a
newer version of EDB to execute the backup.  The catalog in the backup is
from version 1.02.  When the catalog is restored, it is completely messed up
because it is in a different format then the 1.04 EDB expects.

I can't say for sure that this is the case, but I'll keep looking and let
you know what I find.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,


>>Did you create this backup using 1.04 ?
Yes.

>>The catalog in the backup is from version 1.02.  
Yes, this database had been created with 10.2.

>>When the catalog is restored, it is completely messed up
because it is in a different format then the 1.04 EDB expects.

????
Any version of EDB must be able to work with any data of any previous version!
I am writing end-user applications and I must be confident that the underlying database is
relyable! As some stated here, EDB is a different concept than DBIsam, which most of us
have some problems to learn. But it seems that EDB still has basic bugs which don't allow
to use it in business?

Sorry that I have to express my opinion in such a drastic way. You must understand that I
am quite disappointed about EDB just now.

Best regards
Stephan Krämer

Stephan,

<< Any version of EDB must be able to work with any data of any previous
version! >>

I think that we're hitting a language divide here because you're
interpreting my statements wrong every time.  Just for the record - if you
report a problem, then we will fix it.  Unless I specifically say otherwise,
then you should just assume this is the case.

No where did I say that EDB wouldn't be able to work with a previous
version.  In fact, what I said was this:

"I can't say for sure that this is the case, but I'll keep looking and let
you know what I find."

And what I found is that what I thought was the case is indeed the case.
This particular issue will require that you re-backup the database using
1.04 B5 in order to fix the issue, and this will be noted in the release
notes.  The issue is that the catalog is backed up using the latest catalog
format, but is not stamped with the latest version number.  Therefore, when
the backup is restored, the restoration process restores it using the
methods for the older, incorrect version.  This corrupts the catalog during
the restore.

<< I am writing end-user applications and I must be confident that the
underlying database is relyable! As some stated here, EDB is a different
concept than DBIsam, which most of us have some problems to learn. But it
seems that EDB still has basic bugs which don't allow to use it in business?
>>

You have encountered one bug - this one - and it will be fixed only a few
days after you reported it.  The rest of your issues were with the help
files and the installations, and the other that you brought to my attention
via email was the way the EDB Manager dealt with you deleting a migrator
from the configuration path after just putting it there.  All of these
things will be fixed in the next build, as they always are.  I fail to see
where the justification is for the above statement.  And for the record -
I'll put EDB up against DBISAM any day of the week in terms of stability,
performance, and usability.  I know it's natural to be negative towards
learning new things, and I do the same thing myself, but please don't take
the fact that you're unfamiliar with EDB and use it to portray the product
in a negative light.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,

I am sorry that it looks like I hurt you.
I seems that I am not able to explain you what I mean. Sorry for that, I don't want to
keep you off from your work.

Best regards
Stephan

Stephan

<< It seems that I am not able to explain you what I mean. >>

I think you are viewing the situation too bleakly.  Tim does indeed understand
your problems, and based on all the previous years of these newsgroups he responds
like lightning when a bug is found.

Stay with us!

Regards,
Dan