In DBISAM, if a table was physically deleted from the hard drive it would result in an error.  In my opinion this is a good thing as it alerts the customer right away that he has a serious data loss problem.

With ElevateDB however, if a table gets deleted, it just recreates it and continues on.  This is really handy from a programmer perspective, but from a user perspective.... there is nothing to warn them that they have suffered major data loss.  In fact it could be quite some time before they ever discover it.


Has this been an issue for anyone else?  And if so, how do you deal with it?

Dale

Dale,

<< In DBISAM, if a table was physically deleted from the hard drive it would
result in an error.  In my opinion this is a good thing as it alerts the
customer right away that he has a serious data loss problem.

With ElevateDB however, if a table gets deleted, it just recreates it and
continues on.  This is really handy from a programmer perspective, but from
a user perspective.... there is nothing to warn them that they have suffered
major data loss.  In fact it could be quite some time before they ever
discover it. >>

Wouldn't they notice that there's no rows in the table ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


>Wouldn't they notice that there's no rows in the table ?

As you pointed out elsewhere (I think in answer to Rita) you don't get involved with end users

Seriously on tables that are in frequent use (say the main contacts table) even my users would notice, but on an infrequently used table (STD code validation) probably not.

I take Dale's point but since I also want to be able to remove the entire table quickly on occasions I like the feature and wouldn't want to loose it unless EmptyTable made a comeback.

Roy Lambert

Tim


>Wouldn't they notice that there's no rows in the table ?

As you pointed out elsewhere (I think in answer to Rita) you don't get involved with end users

Seriously on tables that are in frequent use (say the main contacts table) even my users would notice, but on an infrequently used table (STD code validation) probably not.

I take Dale's point but since I also want to be able to remove the entire table quickly on occasions I like the feature and wouldn't want to loose it unless EmptyTable made a comeback.

Roy Lambert

Infrequently used tables in particular might not be discovered by the end user for quite a while.  

Also, if the data "quietly" disappears, customers like to point their fingers at the vendor.  If there is definite evidence that the table files are gone.... it is easier to convince them that something (or someone) has compromised their server.

Granted it doesn't happen often, but when it does, it is a pretty serious issue for the customer.

My solution so far is to initially create all my tables in a manner that ensures that they are "physically" created... for instance, using ALTER statements to create things like constraints.  Then I check for them at startup and alert the user if any are missing.  At that point, they can choose to restore from a backup, or just go ahead and let ElevateDB try to correct the problem.

Dale

Agreed.

Even having a property on the database or session called auto-create
tables where it can be set to TRUE or FALSE. (True doing what it does
now, and FALSE raising an exception if the table is opened and doesn't
exist) would be worthy IMO.

Cheers

Adam.

<<Even having a property on the database or session called auto-create
tables where it can be set to TRUE or FALSE. (True doing what it does
now, and FALSE raising an exception if the table is opened and doesn't
exist) would be worthy IMO.>>


Great idea.  Tim, would you consider putting this on the wishlist?

Dale

Adam,

<< Even having a property on the database or session called auto-create
tables where it can be set to TRUE or FALSE. (True doing what it does
now, and FALSE raising an exception if the table is opened and doesn't
exist) would be worthy IMO. >>

I'm sorry, but that simply wouldn't work, given the current design -
ElevateDB would complain after the table is first created that it is
missing.

--
Tim Young
Elevate Software
www.elevatesoft.com

Roy,

<< Seriously on tables that are in frequent use (say the main contacts
table) even my users would notice, but on an infrequently used table (STD
code validation) probably not. >>

FK constraints will ensure that they can't do anything with the main table
(insert/update) if the lookup table gets deleted.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim

><< Seriously on tables that are in frequent use (say the main contacts
>table) even my users would notice, but on an infrequently used table (STD
>code validation) probably not. >>
>
>FK constraints will ensure that they can't do anything with the main table
>(insert/update) if the lookup table gets deleted.

That makes two assumptions 1) I use FK constraints and 2) the lookup table is fully populated / never populated on the fly. Both assumptions are wrong.

1) RI gave me so much grief BD and AD but BE (before delphi and after delphi but before ElevateSoft) that I'll only use them when I can simply switch them off if I need to carry out repair work.

2) Most of my lookup tables are populated by the user on the fly. eg job codes - say the user wants to add a new contact who is the HR Director of the company, they do a lookup, find HR Manager but not Director so add the new code (assuming their permissions allow). Many years ago I learned that maintaining these things on a separate form was a recipe for discontent and if reasonably policed didn't result in many duplicated entries. Something like job codes may be noticed but STD codes - they'll just think hmm haven't got 01933 for Wellingborough in there yet and add it.

Roy Lambert