Hi Tim - thanks for your quick reponse.

>> Are you ever altering any of the tables in your application, or are your
>> users? Or optimizing/repairing tables?

Yes - occasionally when I update my app, I execute a number of ALTER TABLE statements on the database structure. There are 3 "custom" tables in the database (containing customisable fields) and users are able to add/remove/edit DB fields on these tables too.

On a couple of occasions it has been the "custom_xxx" tables that have been 'corrupt', but on other occasions this Error 100 has occurred on tables which haven't had their structure altered for years.

>> Look at the dates and times on the database catalog files and relevant table
>> files when this happens.  If they are different, then the issue is that
>> something is interfering with the proper operation of EDB when it tries to
>> create/move table files during an alter, repair, or optimize operation.

OK - but what exactly am I looking for? If the table content has been updated more recently than the structure, surely the dates will be different anyway?

>> Actually, you can fix this by restoring the .old version of the table files
>> that should be present in the database directory.  There is also an .old
>> file for the edbdatabase.edbcat file during such operations.

That's one of the first things I tried - no joy unfortunately - I tried using the OLD catalog file, then the OLD table files, then both - every combination had the same error. Please see the email I sent you with a link to the latest corrupt database - perhaps that will help?

>> Just to clarify - nothing is getting "corrupted" exactly.  The problem is
>> that the structure in the database catalog does not match the table files,

To help me to understand this Tim - exactly which files are being compared? Is it the .EDBTbl and .EDBCat, or are the .EDBIdx and .EDBBlb involved too? If there is a mismatch for some reason, is there a way of 'rebuilding' the .EDBCat file from the table files?

>> There's no way that a backup is modifying either the catalog or the table
>> files.  You can go ahead and see this for yourself - run a backup a...

Fair enough - it was just a guess.

>> It's certainly possible.  Anti-virus software is a big problem for database
>> applications that copy/move around table files.

This is the strange thing - once my application is setup and configured, nobody moves or copies the database around. To be honest - most of customers wouldn't know how to and they come back to me if they need to move their database to a different location.

I know for a certainty that the customers who have experienced these problems have not moved or changed their databases configuration because we configured their setup for them, and when they've had these problems I've checked it out and their configuration hasn't been altered.

Furthermore, most clients with this problem have been using my software for well over a year (2-3 in some cases) which means they've been using EDB without a problem for that length of time.

You can see why it's worrying that this problem is suddenly starting to crop up!

In addition to my above questions, if you have any more suggestions - even on how to troubleshoot - I'd appreciate any assistance you can give me.

In the next update, we'll be upgrading to EDB 2.04 - perhaps that will help?

Regards,

Hedley

Hedley


As Tim almost said optimising / repairing tables does copy / move tables. I'm less sure about repair but optimisation basically renames the table files, creates new ones and then runs through moving the data over. A lot faster than shuffling data around on the disk to remove space.

Roy Lambert [Team Elevate]

Hedley,

<< Yes - occasionally when I update my app, I execute a number of ALTER
TABLE statements on the database structure. There are 3 "custom" tables in
the database (containing customisable fields) and users are able to
add/remove/edit DB fields on these tables too. >>

Make sure that you're using 2.03 B22.  Some of these issues may have been
related to ALTER TABLE issues, which are all corrected as of B22.

<< On a couple of occasions it has been the "custom_xxx" tables that have
been 'corrupt', but on other occasions this Error 100 has occurred on tables
which haven't had their structure altered for years. >>

If that's the case, then you've definitely got something external
interfering with the proper operation of the engine.

<< OK - but what exactly am I looking for? If the table content has been
updated more recently than the structure, surely the dates will be different
anyway? >>

I assumed that you had a copy of the database catalog and table files that
were exhibiting the problem.  If you do, then comparing the dates/times of
the files will tell you whether any of them were recently created by looking
at their creation dates.  A newer creation date means that it was possibly
copied from another location, which can happen during an alter, optimize, or
repair.  During such operations, EDB creates a new version of each table
file as a temporary file, copies the data over, renames the existing files
to .old, and then renames the temporary files to the existing file names.

<< That's one of the first things I tried - no joy unfortunately - I tried
using the OLD catalog file, then the OLD table files, then both - every
combination had the same error. Please see the email I sent you with a link
to the latest corrupt database - perhaps that will help? >>

Not really - the dates/times are all changed and looking at the database
files will simply tell me what we already know - they don't match the
catalog.

<< To help me to understand this Tim - exactly which files are being
compared? Is it the .EDBTbl and .EDBCat, or are the .EDBIdx and .EDBBlb
involved too? If there is a mismatch for some reason, is there a way of
'rebuilding' the .EDBCat file from the table files? >>

The catalog is the only place where the actual structure is stored.  EDB
computes a checksum on the basic structure information, stores the result in
the catalog, and then stores the checksum in each of the table files also.
If any of the checksums in the table files don't match the catalog, then
you'll see this error.

<< This is the strange thing - once my application is setup and configured,
nobody moves or copies the database around. To be honest - most of customers
wouldn't know how to and they come back to me if they need to move their
database to a different location. >>

If you alter, optimize, or repair a table using 2.03, then you're implicitly
moving around and copying table files (see above).  Remember, EDB assumes
that nothing is going to interfere with its proper operation, which is not
the case with AV software, which routinely blocks such operations or
quarantines the files involved in such operations.

<< I know for a certainty that the customers who have experienced these
problems have not moved or changed their databases configuration because we
configured their setup for them, and when they've had these problems I've
checked it out and their configuration hasn't been altered.

Furthermore, most clients with this problem have been using my software for
well over a year (2-3 in some cases) which means they've been using EDB
without a problem for that length of time.

You can see why it's worrying that this problem is suddenly starting to crop
up! >>

AV software is constantly auto-updated, meaning that the operation of EDB is
irrelevant if their AV software has a change in its behavior that is
interfering with EDB.  This has happened several times with DBISAM.  Have
you actually verified with your customers that a) they have their AV
software disabled for the EDB database directories, and b) that the AV
software does not need to be completely removed to stop
scanning/quarantining certain types of files ?

<< In the next update, we'll be upgrading to EDB 2.04 - perhaps that will
help? >>

It won't be any better than 2.03 B22 in this regard.

--
Tim Young
Elevate Software
www.elevatesoft.com

Thanks for your excellent support Tim.

>> Make sure that you're using 2.03 B22
Actually... looking into it, I believe that almost all the customers who have experienced this problem were using a slightly older version of my app which was built with 2.03 b19. As I do quite a lot of ALTERing TABLEs I suspect we may have found the cause of this problem!

Thanks Tim.

Another quick point which may be helpful :-

We have found with 100% certainty that AVAST! anti-virus corrupts EDB databases when run over a network using a shared EDBConfig file (with a UNC path). This is consistently reproducable and we've had to tell our customers that they can't use AVAST! with our software.

I don't know if there's anything you can do about it (or if you even knew this already) but I thought I'd let you know in case it helps! You can download the free version of AVAST! here :-
http://www.avast.com/free-antivirus-download

Thanks again for your great support!

Regards,

Hedley

Hedley,

<< Actually... looking into it, I believe that almost all the customers who
have experienced this problem were using a slightly older version of my app
which was built with 2.03 b19. As I do quite a lot of ALTERing TABLEs I
suspect we may have found the cause of this problem! >>

Yep, that would do it.

<< We have found with 100% certainty that AVAST! anti-virus corrupts EDB
databases when run over a network using a shared EDBConfig file (with a UNC
path). This is consistently reproducable and we've had to tell our customers
that they can't use AVAST! with our software.

I don't know if there's anything you can do about it (or if you even knew
this already) but I thought I'd let you know in case it helps! You can
download the free version of AVAST! here :-
http://www.avast.com/free-antivirus-download >>

I'll check it out and see what I can find.

--
Tim Young
Elevate Software
www.elevatesoft.com