Hi,

I just have a few questions in regards to the backups. In the manual, it
would appear as though we should use an EDBSession to backup and restore
data. I can completely understand the reason for doing this, so there is
no corruption if someone is writing to a table at the time.

However, at many of our sites, we have different backup procedures in
place. Some take an image of the entire HDD (utilizing shadow copy), and
in some instances we take a basic copy of all the files in certain
directories as a secondary crude backup. (I never like trusting just one
backup).

This works perfectly fine with DBISam. However, with EDB, I attempted to
take a copy of the config and database files, and copy them elsewhere. I
found that I could open up the session, but I couldn't alter the database.

ie -
if the original config file was located in c:\data1\
and the database files were located in c:\data1\db

if I copied these to x:\data1 and x:\data1\db respectively, I could
connect a session to x:\data1, but the database within kept pointing to
c:\data1\db, and if I attempted to alter it it told me that the database
couldn't be locked for exclusive access.

So my question is - am I totally reliant on a EDBSession backup to
execute successfully in order to be able to know my data is safe, or is
there a way to recover / restore data from other backup options should
the EDBSession method fail for whatever reason if I have other backups
(such as images of the HDD, or straight copies)?

Cheers

Adam.

Adam


I use Acronis and have had to restore on a couple of occasions. You have to make sure 1) that no one else is logged in and 2) that the tables / catalog are compatible (eg if the catalog is at v3 and the tables at v1 you've had it).

>if the original config file was located in c:\data1\
>and the database files were located in c:\data1\db
>
>if I copied these to x:\data1 and x:\data1\db respectively, I could
>connect a session to x:\data1, but the database within kept pointing to
>c:\data1\db, and if I attempted to alter it it told me that the database
>couldn't be locked for exclusive access.

You are now entering the realm of catalogs and configurations files - be afraid - be very afraid

What's happening is that you create a new session and promptly point it at a configuration file which in turn is pointing at the live database. This is still in use so ElevateDB tells you to go away when you try and alter the path to the database since that would slightly inconvenience the users.

What you need to do is roughly the following:

1. Copy the whole lot as you are
2. Delete any files starting with EDBConfig (assuming you haven't customised things) in the directory you've copied to
3. Create a new session pointing it at the directory you've copied to
4. Add a database pointing at the copied data.

You're back in business.

In the unlikely event that you have to copy the backup back to live then unless you've altered table structures you should just be able to copy the appropriate table files over.

What I did since I was running the system as I developed was to add in options to export / import table data in csv format.

Roy Lambert [Team Elevate]

ps sorry for the levity but it is Friday

Adam,

<< I just have a few questions in regards to the backups. In the manual, it
would appear as though we should use an EDBSession to backup and restore
data. I can completely understand the reason for doing this, so there is no
corruption if someone is writing to a table at the time. >>

Correct.

<< if I copied these to x:\data1 and x:\data1\db respectively, I could
connect a session to x:\data1, but the database within kept pointing to
c:\data1\db, and if I attempted to alter it it told me that the database
couldn't be locked for exclusive access. >>

This is not a backup issue, exactly.  The issue here is simply that you need
to use relative paths for your databases in order to allow them to be copied
without having to alter/reset the database path in the new location.

So, for example, instead of using 'c:\data1\db' for the database path, just
use 'db'.  So, when you point your configuration path to the new location of
'x:\data1', the database will still be where EDB expects it to be, in
'x:\data1\db'.

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

Thanks for your reply...

> << I just have a few questions in regards to the backups. In the manual,
> it would appear as though we should use an EDBSession to backup and
> restore data. I can completely understand the reason for doing this, so
> there is no corruption if someone is writing to a table at the time. >>
>
> Correct.

Excellent... just like DBISam. That's what I wanted to hear. <vbg>

I used interbase with one of my applications years ago (before
discovering DBISam), and I found it quite sensitive / easy to break.
Great to hear that EDB is much more robust.

> << if I copied these to x:\data1 and x:\data1\db respectively, I could
> connect a session to x:\data1, but the database within kept pointing to
> c:\data1\db, and if I attempted to alter it it told me that the database
> couldn't be locked for exclusive access. >>
>
> This is not a backup issue, exactly.  The issue here is simply that you
> need to use relative paths for your databases in order to allow them to
> be copied without having to alter/reset the database path in the new
> location.
>
> So, for example, instead of using 'c:\data1\db' for the database path,
> just use 'db'.  So, when you point your configuration path to the new
> location of 'x:\data1', the database will still be where EDB expects it
> to be, in 'x:\data1\db'.

Fantastic! I didn't realise that. That makes life much more easier!

> If you have any other questions, please let me know.

Oh - I will be sure to.

Cheers

Adam.

Hi Roy,

Thanks for your reply.

> I use Acronis and have had to restore on a couple of occasions. You have to make sure 1) that no one else is logged in and 2) that the tables / catalog are compatible (eg if the catalog is at v3 and the tables at v1 you've had it).

No worries. Since the backup will be backing up both the catalog as well
a the tables, I think I should be right then...

> You are now entering the realm of catalogs and configurations files - be afraid - be very afraid

Oh don't tell me that. I've just gotten up the courage to write my next
significant application in EDB!  

> What's happening is that you create a new session and promptly point it at a configuration file which in turn is pointing at the live database. This is still in use so ElevateDB tells you to go away when you try and alter the path to the database since that would slightly inconvenience the users.
>
> What you need to do is roughly the following:
>
> 1. Copy the whole lot as you are
> 2. Delete any files starting with EDBConfig (assuming you haven't customised things) in the directory you've copied to
> 3. Create a new session pointing it at the directory you've copied to
> 4. Add a database pointing at the copied data.
>
> You're back in business.
>
> In the unlikely event that you have to copy the backup back to live then unless you've altered table structures you should just be able to copy the appropriate table files over.

Excellent - this is exactly what I wanted to hear. It sounds as though
the only directory I need to worry about is that where the datafiles are
located, but I'll still back up both just to stay on the safe side.

> What I did since I was running the system as I developed was to add in options to export / import table data in csv format.

Interesting thought. Unfortunately many of my tables contain BLOB's
which makes CSV exporting much more difficult.

Cheers

Adam.

Adam


>Interesting thought. Unfortunately many of my tables contain BLOB's
>which makes CSV exporting much more difficult.

So do mine. Foretunately ElevateDB seems able to cope with them

Roy Lambert [Team Elevate]

>> Interesting thought. Unfortunately many of my tables contain BLOB's
>> which makes CSV exporting much more difficult.
>
> So do mine. Foretunately ElevateDB seems able to cope with them

Interesting - so blob data can be exported to a CSV? I'll have to check
this out!

Cheers

Adam.

Adam,

<< Interesting - so blob data can be exported to a CSV? I'll have to check
this out! >>

Yes, it is exported as a hex string, just like a binary constant (minus the
'X' prefix):

http://www.elevatesoft.com/manual?action=viewtopic&id=edb2sql&topic=Binary_Types

If you have any other questions, please let me know.

Tim Young
Elevate Software
www.elevatesoft.com

Hi Tim,

> Yes, it is exported as a hex string, just like a binary constant (minus
> the 'X' prefix):

Beautiful - thanks for that.

Just wondering - would it be difficult to port those changes across to
DBISam's DBSys? (or is this something that would require an actual
change to DBISam itself)?

Cheers

Adam.

Adam,

<< Just wondering - would it be difficult to port those changes across to
DBISam's DBSys? (or is this something that would require an actual change to
DBISam itself)? >>

Yes, it's pretty difficult to deal with.  EDB has the natural ability to do
this because all of the lower-level "value" classes were completely
re-written to allow it, whether they be row values, parameter values,
constants, etc.

Tim Young
Elevate Software
www.elevatesoft.com