I have some databases listed in the EDBCfg file. Now one or more of them will be removed
physically, that means the database folder to which the EDBCfg points will be removed.
The next time when I open the database from the session's list, the folder will be
automatically recreated with an empty catalog and no tables.

Questions:
- What is the easiest way to detect if a TDatabase.Open had really opened an existing
database?
- Sometimes it is better to check the databases list before attempting to open a database.
What is the best way to do this?

Thanks
Stephan Krämer

Stephan


Why not just DROP the database from the list?

Roy Lambert

Roy

>>Why not just DROP the database from the list?

This was not the question. Please read them again.
This is only the consequence.
But my question was how to detect when I should drop the database. THere may be some
fiddling around with Windows file checking, but my question was if there is a more
straightforward way inside EDB. Also this automatic recreation without any notice is not
what I expect from a database system.

Best regards
Stephan Krämer

Stephan,

<< I have some databases listed in the EDBCfg file. Now one or more of them
will be removed physically, that means the database folder to which the
EDBCfg points will be removed. The next time when I open the database from
the session's list, the folder will be automatically recreated with an empty
catalog and no tables.

Questions:
- What is the easiest way to detect if a TDatabase.Open had really opened
an existing database? >>

You're thinking of the existence of a database in the wrong way.  In EDB,
the existence of an object is determined by whether it exists in the system
Configuration database, or in a user database.  Whether or not the object
has files on disk for storage yet is irrelevant to EDB, which is why it
creates them as necessary.  In other words, as long as EDB says that a
database exists, then it exists.  Whether the database tables are empty or
not must be determined by opening a database table and checking to see if
there are any rows present or not.  EDB is not like DBISAM in that the
presence of certain files determines the existence of an object.

<< - Sometimes it is better to check the databases list before attempting to
open a database. >>

I'm not sure what you mean by "check the databases list" ?  What are you
checking for ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Stephan,

<< Also this automatic recreation without any notice is not what I expect
from a database system. >>

That's how database catalogs work.  They serve as the directory of objects
in the database(s), not the files on disk.  The files on disk are just
storage locations for table data.  EDB has no way of knowing whether you
deleted the table files directly using the OS or whether this is a fresh
installation and creation of the database.  To do so would require updating
the database catalog(s) whenever a table is updated, and that is a big
concurrency issue that is avoided like the plague.

--
Tim Young
Elevate Software
www.elevatesoft.com

Hello Tim,

>>
That's how database catalogs work.  They serve as the directory of objects
in the database(s), not the files on disk.  The files on disk are just
storage locations for table data.  EDB has no way of knowing whether you
deleted the table files directly using the OS or whether this is a fresh
installation and creation of the database.  To do so would require updating
the database catalog(s) whenever a table is updated, and that is a big
concurrency issue that is avoided like the plague.
<<

You may be right if you think in terms of company databases. But as far as I understood,
DBIsam and also EDB were not designed for large business databases. Instead, both are
designed as former BDE replacement and now as alternatives to other lightweight databases.
Those databases are used for end-user desktop apps, because they don't need extra users'
work like M$-SQL Server or Interbase etc. We as developers like databases like DBisam,
EDB, etc. because we can afford them and because distribution with our own apps is free.
With respect to the requirements of those apps, I completely disagree with your statement.
For example, my applications (see www.sportsoftware.de must work as standalone apps
as well as in networks. Also the users do touch the datafolders manually, may it be by
accident or intentionally, when exchanging data. Nobody of them would understand why the
database system like EDB will not complain about missing data.

For me personally and all of my customers, the presence of data is defined by their
physical existence and not by a (wrong) definition anywhere. This can be easily checked by
the engine on startup, comparing the database definitions to the real files. Also this can
easily be checked if one opens a specific database from the session's list (and not
silently create a new database without data...). That's why I asked if there is some
straightforward method to do this. Of course you are right, this can't be done "online".
But this is not necessary for me.
Well, it seems that EDB is not the right database for my purpose. I think I will fall back
to DBIsam or use another DB.

Best regards
Stephan Krämer

Hi,

What is wrong with using fileexists at the start of your app ???

Don't write off EDB so quickly...
It's an acquired taste

Wim


Stephan Krämer <stkraemer@sportsoftware.de> wrote


That's why I asked if there is some
straightforward method to do this. Of course you are right, this can't be done "online".
But this is not necessary for me.
Well, it seems that EDB is not the right database for my purpose. I think I will fall back
to DBIsam or use another DB.

Best regards
Stephan Krämer

Wim,


>>What is wrong with using fileexists at the start of your app ???

Now, what is EDB actually? An improvement to DBisam  or not?
Yes, with DBIsam you must check with fileexists, since you don't have a database catalog.
Instead the "catalog" exists in code, means some checking procedures.
But EDB has a database catalog, whose task among others should be to check if the
definitions do match what is there physically. As I pointed out, this need not to be
automatically but just some checking procedures which one can invoke when he wants.
Even with DBIsam it is not necessary to check if a table exists before opening it. You
just get an exception which tells you that something is wrong. Well, with EDBTable this is
the same, but I would expect this also for TEDBDatabase.Open.

Best regards
Stephan Krämer

Stephan Krämer <stkraemer@sportsoftware.de> wrote in
news:321549F9-812E-4014-9546-80B2B4C7D036@news.elevatesoft.com:

> Questions:
> - What is the easiest way to detect if a TDatabase.Open had really
> opened an existing database?

Stephan,

If you have to handle the problem of someone removing your datafiles (and
if you can be sure they move all of them at once) you could add a special
table to the database and fill one record in it with some fixed data, and
then always open that table first. If you find the fixed data in it, then
the database hasn't been moved.

--
Chris
(XP-Pro + Delphi 7 Architect + DBISAM 4.25 build 4 + EDB 1.04 build 3)

Chris,


>>>
If you have to handle the problem of someone removing your datafiles (and
if you can be sure they move all of them at once) you could add a special
table to the database and fill one record in it with some fixed data, and
then always open that table first. If you find the fixed data in it, then
the database hasn't been moved.
<<<

Yes, there are many ways to check this out by hand. But this was not my question... So
far, I don't have any precise answer from Tim if EDB will handle this, yes or no. Tim is
also asked to comment my point of view which I explained to him.

Best regards
Stephan Krämer