Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 4 of 4 total |
All indexes of a table were dropped |
Thu, Oct 31 2013 4:40 PM | Permanent Link |
Chris | Hi there,
we have an isue with two of our clients having had all indexes dropping off from one table. The table itself was still intact and DBIsam recreated a primary key on the RecordID. So at one stage further processing wasn't possible due to using an index directly. Both clients had a different table that lost its indexes. Our development team is using DBIsam 4.32 Build 1. Does anybody here had the same issue? Is a solution at hand? Or is more information required (which)? Cheers, Klaus |
Thu, Oct 31 2013 5:40 PM | Permanent Link |
Raul Team Elevate | On 10/31/2013 4:40 PM, Chris wrote:
> we have an isue with two of our clients having had all indexes dropping off from one table. > The table itself was still intact and DBIsam recreated a primary key on the RecordID. So at one stage further processing wasn't possible due to using an index directly. > Both clients had a different table that lost its indexes. > Our development team is using DBIsam 4.32 Build 1. > Does anybody here had the same issue? > Is a solution at hand? > Or is more information required (which)? Chris, Have not heard of this happening - we've been running DBISAM for years and so have others). Couple of questions are in order : 1. Is this repeatable ? 2. is there a backup file for the tables in question ? You can copy them out, rename back and see if indexes are present in there. 3. Does your application alter the tables at all ? One way this would happen is if one alters the table but forgets to actually load the indexdefs - then the fields would be OK but indexes would be deleted (and if there is primary index DBISAM created one for RecordID). code similar to : .... FieldDefs.Update; //do something with fielddefs like add/remove fields AlterTable; //at this point indexes would be gone ... should do instead .... FieldDefs.Update; //do something with fielddefs like add/remove fields IndexDefs,Update; AlterTable; //now indexes OK ... Raul |
Fri, Nov 1 2013 4:04 AM | Permanent Link |
Roy Lambert NLH Associates Team Elevate | Chris
Only three possibilities come to mind: 1. Its your code 2. Someone deleted a table at Windows level 3. The AV software did it Whatever's happened, unless its your code, diagnostics at this point are pretty much impossible. Because of how DBISAM stores its indices and their definitions my bet would be on either 2 or 3. If its 2 you have no chance of ever finding out. If 3 then get your customers to check the AV logs and quarantine to see if that shows anything. If possible get them to exclude the directory with your tables from the AV software. Roy Lambert [Team Elevate] |
Mon, Nov 11 2013 10:49 PM | Permanent Link |
Chris | Hey Roy,
it has been a whil since you answered, so i am sorry not having been back to this earlier. thanks for your answer. I can exclude 1, am not 100% sure about 2, but think 3 may be the solution. We talked to our 2 out of 8500 clients having had this issue and asked them to have a look into the logs, but they haven't been back to us yet. Both clients have no idea what anti virus suite they have and how to handle their computer. They have to wait until their service technician is in again. As soon as we have an answer to this I will post it here. Our developers added a check for this issue (differences between the index structure of the current database and the meta data) in our maintenance tool, so it is now classified only as a minor problem. Cheers, Klaus |
This web page was last updated on Saturday, May 4, 2024 at 12:54 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |