I have copied some older versions of my datafiles back from a backup, but now the catalogue file doesn't match the older file and I have no idea I can bring the catalogue file to the same version as the data files?

How can I create a ctatalogue from datafiles which will than not anymore throw a version mismatch?

Rolf

>I have copied some older versions of my datafiles back from a backup, but now the catalogue file doesn't match the older file and I have no idea I can bring the catalogue file to the same version as the data files?
>
>How can I create a ctatalogue from datafiles which will than not anymore throw a version mismatch?

You can't. Unlike DBISAM ElevateDB has all of the structure information in the catalog if that's lost you've had it.

Roy Lambert [Team Elevate]

Roy

I can't realy believe that! That would be a catastrophe than. If we would
have a one File integrated database like Access or MS SQL, everything will
be fine, as the user can't copy any files at all, but now as we have a
multifile Database, this would be a disaster and I have no idea what I can
do then. I'm 100% sure  my customers will do this sooner or later, as they
have done this right often in my DBISAM version of tha application.

So the big question must be: How can I prevent my customers from copying
files around? What can I do if it happened anyway?

Regards
Rolf


"Roy Lambert"  schrieb im Newsbeitrag
news:B4E77410-32C4-4D67-866C-25501E575653@news.elevatesoft.com...

Rolf

>I have copied some older versions of my datafiles back from a backup, but
>now the catalogue file doesn't match the older file and I have no idea I
>can bring the catalogue file to the same version as the data files?
>
>How can I create a ctatalogue from datafiles which will than not anymore
>throw a version mismatch?

You can't. Unlike DBISAM ElevateDB has all of the structure information in
the catalog if that's lost you've had it.

Roy Lambert [Team Elevate]

Rolf


>I can't realy believe that! That would be a catastrophe than. If we would
>have a one File integrated database like Access or MS SQL, everything will
>be fine, as the user can't copy any files at all, but now as we have a
>multifile Database, this would be a disaster and I have no idea what I can
>do then. I'm 100% sure my customers will do this sooner or later, as they
>have done this right often in my DBISAM version of tha application.
>
>So the big question must be: How can I prevent my customers from copying
>files around? What can I do if it happened anyway?

Users / Customers will always do what you don't want. I sometimes think that's a fundamental law of the universe.

1: Always back up the catalog along with the data.

2: Educate your customers (often a total waste of time but you have to try)

3. Provide facilities to do the same as copying the file (in my case I have export / import to do this)

4. Back up at least daily, remembering to back up the catalog

5. Do the best you can to keep the catalog in sync across multiple versions / customers

Roy Lambert [Team Elevate]

Rolf

The better and safe way is using client/server architecture.
You only need to provide IP address to the client side and therefore you can
hide the database folder from regular users using Active Directory rules.

I do that and it is a rock solution.

Eduardo

Roy,

If there is only one database with the app, would you recommend putting the Config files in the same directory as the data? Or should they always be kept in separate directories?

Here are a couple of solutions off the top of my head that may help protect the Config files. I'm sure others may have ways of improving on it or alternative ways of preventing the user from shooting himself in the foot.

1) To prevent the user from copying/deleting the Config files, why not write a Delphi utility to copy the Catalog directory to a zip file and put it into the database directory. This backup procedure would only be run if the database is opened successfully. It would keep the last 'n' catalog zip files around in the data directory.

2) The other alternative would be have another EDB database that backs up the Catalog's of all the databases as Stores or in a Blob file. If the Catalog to one of the databases is damaged, a utility is run to restore the Catalog files. This backup database could probably be set to ReadOnly when the utility program exits to prevent user from mucking about with it. It can also check the databases every hour/day by trying to open them and report any errors.

Barry

Barry

>If there is only one database with the app, would you recommend putting the Config files in the same directory as the data? Or should they always be kept in separate directories?

That's the official line, and its what I've always tended to do, mainly because my main app can be multi-database. With a 1:1 relationship I, personally, don't see a problem with just one directory (I'd probably throw the exe in there as well).

>Here are a couple of solutions off the top of my head that may help protect the Config files. I'm sure others may have ways of improving on it or alternative ways of preventing the user from shooting himself in the foot.
>
>1) To prevent the user from copying/deleting the Config files, why not write a Delphi utility to copy the Catalog directory to a zip file and put it into the database directory. This backup procedure would only be run if the database is opened successfully. It would keep the last 'n' catalog zip files around in the data directory.
>
>2) The other alternative would be have another EDB database that backs up the Catalog's of all the databases as Stores or in a Blob file. If the Catalog to one of the databases is damaged, a utility is run to restore the Catalog files. This backup database could probably be set to ReadOnly when the utility program exits to prevent user from mucking about with it. It can also check the databases every hour/day by trying to open them and report any errors.

If you use ElevateDB's in-built backup you can simply include the catalog

BACKUP DATABASE <Name> AS <BackupName> TO STORE <StoreName> [TABLES <TableName> [,<TableName>]] [DESCRIPTION <Description>] [COMPRESSION <Compression>] [INCLUDE CATALOG [ONLY]] [EXCLUDE PUBLISHED UPDATES].

The config files don't need as much protection because they're easier to recreate. Its the catalog that's the pain.

Roy Lambert [Team Elevate]

Rolf,

<< I have copied some older versions of my datafiles back from a backup, but
now the catalogue file doesn't match the older file and I have no idea I can
bring the catalogue file to the same version as the data files?

How can I create a ctatalogue from datafiles which will than not anymore
throw a version mismatch? >>

Did you not backup the database catalog along with the table files ?  You
should always backup the catalog along with the table files, and then you
can selectively choose whether you wish to restore the catalog if you have
to restore certain tables.

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

Tim Young
Elevate Software
www.elevatesoft.com

Tim

It is an enduser disaster question for me. Today some of my customers do
from time to time copy some single tables back from the webserver and
replace it in the local DB. In DBISAM this is not a big deal, as my
application checks the versions of the tables and does atomaticly update the
db structure to the needed level of my application. I'm not talking about a
backup or so. Even from a backup I will not be able to restore a single
table, with a diffrerent strucutre than my actual DB has. Copy the schema
istn't an option at all as else all other tables with different versions are
not anymore working.

In EDB2 this will result in a disaster. Will I be able to read the table
Version of the exsiting datafiles at all, if the schema is different to the
datafile or is the version number also be stored in the schema file?
Hopefully not. If I can find out what version (my custom Major/Minor
version), it would be simpler to repair and bring the table in the correct
structure.

This complete thing sounds like a big time bomb to me and I'm very afraid to
get into big troubles with my customers by this.

Regards
Rolf

"Tim Young [Elevate Software]"  schrieb im Newsbeitrag
news:0C379AE7-76CA-4E36-9F6B-4D4113A7832F@news.elevatesoft.com...

Rolf,

<< I have copied some older versions of my datafiles back from a backup, but
now the catalogue file doesn't match the older file and I have no idea I can
bring the catalogue file to the same version as the data files?

How can I create a ctatalogue from datafiles which will than not anymore
throw a version mismatch? >>

Did you not backup the database catalog along with the table files ?  You
should always backup the catalog along with the table files, and then you
can selectively choose whether you wish to restore the catalog if you have
to restore certain tables.

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

Tim Young
Elevate Software
www.elevatesoft.com

Rolf


I've been through this personally. In my case it was moving data from the live system to my development system so that I could make sure I was operating on real data. My solution was to build in an export and import facility. Not quite as easy as simply copying a couple or three files but it works.

I know Tim's good but I don't see anything much more he can do without a mass of alterations to ElevateDB. He did make an alteration a while back (can't remember exactly what or which version) so the problem was eased slightly but the fact remains that meta data and data are now split. Even if you can read the version from the table files I'm doubtful you'll be able to do anything with them.

The difference is that with DBISAM the table carried its own meta data so you have the necessary information to open the table and then alter it. With ElevateDB you can't even open the table because the meta data doesn't match the data in the files. Essentially ElevateDB no longer has any idea of what bit of data goes or comes from where.

I can come up with a few suggestions but a lot depends on why your users are doing the copying and how amenable they would be to using a different approach, and the level of difference between the structures.


Roy Lambert [Team Elevate]