Rolf,

<< 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. >>

You're going to have to tell them to stop doing that, especially if the
structures of your tables are constantly changing.  As Roy stated, they'll
need to use import/export instead.

<< 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? >>

It's simply a checksum value, so it won't do you any good to know the actual
value.  The important piece of information is whether it matches the
checksum for the table structure that is stored in the database catalog.

<< 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. >>

How could you do that ?  The structure is only stored in the catalog, not in
the table files.  EDB would have no way of knowing what the original
structure was, period, and without that, it can't alter the structure at
all.

<< 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. >>

EDB <> DBISAM, especially in this regard.  There are changes required to the
general overall approach to how the database catalog/table files are handled
with EDB, and you'll need to convey these to your customers also.  In
general, allowing users direct access to database files is always
problematic, especially if they're not careful or don't know what they're
doing.

Tim Young
Elevate Software
www.elevatesoft.com

Tim,

<<You're going to have to tell them to stop doing that, especially if the
structures of your tables are constantly changing.  As Roy stated, they'll
need to use import/export instead.>>

Of course I will make very clear to them, btu I'm suer they will do it
anyway sooner or later.

<<It's simply a checksum value, so it won't do you any good to know the
actual
value.  The important piece of information is whether it matches the
checksum for the table structure that is stored in the database catalog.>>

I'm not talking about the internal version (checksum), but my user defined
Major/Minor version of the table. With this version numbers I do exactly
know what I must do in the schma to bring it at the same level as in the
real DB.

<<How could you do that ?  The structure is only stored in the catalog, not
in
the table files.  EDB would have no way of knowing what the original
structure was, period, and without that, it can't alter the structure at
all.>>

I would be able to use the correct cataloge from the webserver in a
temporary directory and and bring that table there into the same version as
my real DB has. And after that I can copy it over to my real DB, as the
cataloge should now be the same. As far I can see, this sould work, but I
must known my custom User-Version of the table, so I know what schema
updates must be done on that table.

Of course I hope this will never be the case and my customers hear on me,
but I must know how I can help if they do this anyway.

Regards
Rolf

Rolf,

<< I'm not talking about the internal version (checksum), but my user
defined Major/Minor version of the table. With this version numbers I do
exactly know what I must do in the schma to bring it at the same level as in
the real DB. >>

Yes, but EDB *does* not, and any attempt by it to do anything to the table
files will most likely result in a *lot* of AVs because the structure won't
match.

<< I would be able to use the correct cataloge from the webserver in a
temporary directory and and bring that table there into the same version as
my real DB has. And after that I can copy it over to my real DB, as the
cataloge should now be the same. As far I can see, this sould work, but I
must known my custom User-Version of the table, so I know what schema
updates must be done on that table. >>

Sorry, but this just isn't a workable solution at all.  The catalog has all
sorts of dependencies in it between various objects, including tables, and
so you can't just pop a new catalog into play on a single table and have it
work in any way.   This is the nature of RI and how database catalogs work.

Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" wrote:

>>Yes, but EDB *does* not, and any attempt by it to do anything to the table
>>files will most likely result in a *lot* of AVs because the structure won't
>>match.

Tim,

Is there a CatalogValidate() function we can call BEFORE opening/using the database to determine if the Catalog files have been changed, corrupted, or do not match the database files? If we run this function before the database is opened, we can notify the user right away there is a problem, and will eliminate the AV's later on.

Barry

Barry,

<< Is there a CatalogValidate() function we can call BEFORE opening/using
the database to determine if the Catalog files have been changed, corrupted,
or do not match the database files? If we run this function before the
database is opened, we can notify the user right away there is a problem,
and will eliminate the AV's later on. >>

Please do not misunderstand:  there are *no* AVs if you use mismatched table
files with the catalog.   EDB checks the special checksum in the table files
against the catalog, and if they don't match, it simply issues an error
("'The internal structure does not match the structure in the catalog").
That's it, and it's only for the affected table, other tables will still
work just fine.

The solution for such a problem is to:

1) Move the affected table files to a safe folder (note: move, not copy).
2) Alter the table in EDB so that the structure is correct for the table
files that you're trying to use.
3) Copy the affected table files back into the database folder.
4) If the structure that you defined is correct, then you'll be able to open
the table.  If not, then you'll get the same checksum error as before ("'The
internal structure does not match the structure in the catalog").

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

Tim Young
Elevate Software
www.elevatesoft.com

<<<
1) Move the affected table files to a safe folder (note: move, not copy).
2) Alter the table in EDB so that the structure is correct for the table
files that you're trying to use.
3) Copy the affected table files back into the database folder.
4) If the structure that you defined is correct, then you'll be able to open
the table.  If not, then you'll get the same checksum error as before ("'The
internal structure does not match the structure in the catalog").<<<

To know in which state I must alter the table, I must know the Major/Minor
Version of the wrong table. You didn't answer me if it is stored in the data
files or in the schema. Can I still access the version info on such a
mismatch table?

Regards
Rolf

Rolf,

It's a mistake to think of a database as a set of files, and the fact that EDB is using a set of files to store data and metadata doesn't transform it into a set of files serving an application.
IMO, you would ease your life by convincing your users not to deal with a full DBMS as if it was a set of simple data files, it's going to make you and them happier

--
Fernando Dias
[Team Elevate]

Tim will know for sure but i believe it's in the catalogue together with
rest of the structure information - note that actual table file is not
created until its needed hence the meta data is all in the catalogue.

How often do your table structures change in reality?

A regular backup of data and catalogue would likely provide adequate
protection and ability to recover if needed.

Raul

On 9/18/2012 8:48 AM, Rolf Frei wrote:
> To know in which state I must alter the table, I must know the
> Major/Minor Version of the wrong table. You didn't answer me if it is
> stored in the data files or in the schema. Can I still access the
> version info on such a mismatch table?
>

>A regular backup of data and catalogue would likely provide adequate
>protection and ability to recover if needed.

Raul,

I agree with you. If the user modified/restored/altered the catalog files, the application should throw an error when it starts and force the user to immediately restore the catalog and the data files. If it is a C/S application, then the database directory (including catalog directory) should require Administrator rights to modify the files (from an OS window). I'm not sure how you would secure these files for an embedded application though. Maybe securing the database/catalog directories would make for a good EDB article?

Barry
If the user insists on shooting himself in the foot, he darn well better know where the hospital is.

Barry,

<< I agree with you. If the user modified/restored/altered the catalog
files, the application should throw an error when it starts and force the
user to immediately restore the catalog and the data files. If it is a C/S
application, then the database directory (including catalog directory)
should require Administrator rights to modify the files (from an OS window).
I'm not sure how you would secure these files for an embedded application
though. Maybe securing the database/catalog directories would make for a
good EDB article? >>

There's really no way to secure the files 100% in direct-access application,
short of possibly using threads that impersonate a specific user account
that performs all database access and is the only user account with access
to the database directory(ies).  In such a case, it's much easier to just
simply install the EDB Server as a service under that user account, use
remote sessions, and be done with it.

Tim Young
Elevate Software
www.elevatesoft.com