Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 10 of 23 total |
Is automatically recreating missing tables a good thing? |
Fri, Jul 23 2010 10:18 AM | Permanent Link |
Dale Derix | 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 |
Sat, Jul 24 2010 10:11 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Sat, Jul 24 2010 11:27 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sat, Jul 24 2010 11:41 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Sat, Jul 24 2010 2:19 PM | Permanent Link |
Dale Derix | 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 |
Mon, Jul 26 2010 1:18 AM | Permanent Link |
Adam H. | 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. |
Mon, Jul 26 2010 9:32 AM | Permanent Link |
Dale Derix | <<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 |
Tue, Jul 27 2010 8:37 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Tue, Jul 27 2010 8:40 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Jul 27 2010 9:11 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | 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 |
Page 1 of 3 | Next Page » | |
Jump to Page: 1 2 3 |
This web page was last updated on Tuesday, May 14, 2024 at 07:14 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |