Hi there,

we are using ElevateDB with many Customers .. but we often are having damaged databases ... well step first is to run our "repair-tool" that just goes through the tables and issue a "repair" on each table.
We noticed that this doesnt fix the daily-problems that appear.

1.
Many customers are having damaged index files which are not recognoized by the repair command ... deleteing the *.edbidx solves that problem .. but rebuilding the index is something the index-command should do aswell.

2.
Sometimes we have customers that are having damaged blob-files which are not recognized by the repair command.
Thats quite bad cause you would have to open each table and access every record to you see if the blob-error appears... fixing is mostly done by simply "null-ing" the damaged field ... sometimes it also worked to export and reimport the table to fix it ...  but nulling a damaged field is a quite easier way.

if the repair-command could do that stuff too .. our hotline would by much easier.

Volker

ElevateDB is usually very stable. If you are "often are having damaged databases" then there's something seriously wrong either at your customer's site or with your software. You would have a much better affect on your hotline by resolving the problems rather than patching round them.

If you want REPAIR to rebuild the index delete the index file before running it. I asked Tim for this to be built in as a switch but its no big deal to delete the fiiles myself.

You say "having damaged blob-files". Is that what you actually mean? If so ElevateDB's repair system doesn't touch anything not stored in the database. If you mean BLOB columns then all ElevateDB can really do is check that the pointers to where the data lies is correct - it knows nothing about the data itself.

To allow people on these newsgroups to provide help can you answer a few questions please:

1. Is your software client/server or file/server? (if the latter then a possible cause of corruption is bad network equipment)
2. Is your software single threaded or multi threaded? (if the latter not implementing isolation properly is a major cause of corruption)
3. Which version of Delphi?
4. WHich version of ElevateDB?
5. Is there any common set of tables that are corrupted or is it all over the place?

Roy Lambert [Team Elevate]

Sure patching around is not a that good solution .. but the only one!

We are using elevate File-based.. (for ~5 years)
single threaded ..
delphi 2006 (for that product)
Elevate Version 2.11
the damages appears all over the place .. i think it mostly happening due to network errors ... or bad virus-scanners ...
we always had such problems with elevate .. dont understand me wrong .. we do not have such errors often .. but they exist.

e.g. the SQLAnywhere-Database uses a BackLog to fix such errors by re-processing the last commands you could  just unplug the computer and it would fix it self and finish pending opertions... so yes it is possible to use file-based databases on network-shares.

Sure using the Database-Server-Process would mostly solve the issues ... but our customers are having mostly 1~3 single computers ... and a nas-drive .. no way of using a server-process.... "Mrs. Marple please turn on your pc i've to work ..."

On my current point of view elevate misses some kind of automatically fixing feature.
Detecting unfinished write-operations and fixing that stuff.

Volker

>Sure patching around is not a that good solution .. but the only one!

Understand - but a shame.

>We are using elevate File-based.. (for ~5 years)
>single threaded ..
>delphi 2006 (for that product)
>Elevate Version 2.11

I also use D2006 and mainly file sharing - started with DBISAM V2.

>the damages appears all over the place .. i think it mostly happening due to network errors ... or bad virus-scanners ...
>we always had such problems with elevate .. dont understand me wrong .. we do not have such errors often .. but they exist.

I'd guess network problems rather than AV software. Are they generally wired or wireless networks? If the latter then random dropouts could be the problem. First wireless stuff I bought lost its connection when the hub as <5m away from the PCs

>e.g. the SQLAnywhere-Database uses a BackLog to fix such errors by re-processing the last commands you could just unplug the computer and it would fix it self and finish pending opertions... so yes it is possible to use file-based databases on network-shares.

I don't dispute what you say (I have no experience with SQL Anywhere) but I can't picture how it can do that in F/S mode.

>Sure using the Database-Server-Process would mostly solve the issues ... but our customers are having mostly 1~3 single computers ... and a nas-drive .. no way of using a server-process.... "Mrs. Marple please turn on your pc i've to work ..."

Tell them to replace the NAS with a standard PC <vbg>

I've had two NAS devices - both were eventually treated with a large hammer. I now have an old Dell PC sitting there with the screen turned off most of the time.

>On my current point of view elevate misses some kind of automatically fixing feature.
>Detecting unfinished write-operations and fixing that stuff.

I can't see how Tim can do that for F/S. Once the data is pushed over the wire the local engine has lost sight of it unless you have something sitting at the other end to say "yup got that, processed ok" then how can ElevateDB know there's an unfinished write?


Roy

well we have customers having a Windows-2010-SBS with 1 GBIT-Lan-Connection having db-problems ... *g* ..
you will never be able to get rid of transmission problems ..

well i can't  get to specific ..

but before the Database starts a operation .. the task / SQL-Command gets stored in the Log-File ...
than it starts with that operation ... after being sure the operation has been finished this got also written into the log-file.

So if something goes wrong log-file would know if something gone wrong .. this Log-File should be stored seperatly from the database on another location .. for example a second nas *G* .. so if the harddrive of NAS 'A' dies the database could regenerate it self by using the log-replay from NAS 'B' .. and the other way round ...

well its a nice feature ... if the database gets corrupted it can be re-created by the log-replay .. and if the log get's damaged it can be just deleted ... if you store both on diffrent devices... in any constelation you can just simple pull the power plug ...

Volker

>well we have customers having a Windows-2010-SBS with 1 GBIT-Lan-Connection having db-problems ... *g* ..

Ouch!

>
>well i can't get to specific ..
>
>but before the Database starts a operation .. the task / SQL-Command gets stored in the Log-File ...
>than it starts with that operation

No problem with that - written systems using a transaction log several times

>... after being sure the operation has been finished this got also written into the log-file.

This is the bit that baffles me, but then lots of things baffle me. I'm used to it.

Roy

Volker,

<< we are using ElevateDB with many Customers .. but we often are having
damaged databases ... well step first is to run our "repair-tool" that just
goes through the tables and issue a "repair" on each table.  We noticed that
this doesnt fix the daily-problems that appear. >>

If you're using multi-user, file-sharing access, then the only way to get
around this is to use the ElevateDB Server and stop using file-sharing.
Your problems are coming from the file-sharing model, not ElevateDB.

<< 1.Many customers are having damaged index files which are not recognoized
by the repair command ... deleteing the *.edbidx solves that problem .. but
rebuilding the index is something the index-command should do as well. >>

Example please.  You haven't contact us for support regarding any of these
issues.  If they're important to you, then you should open a support session
with us and send us the files so that we can tell you what's happening.
Posting this type of vague information here is pointless and of little use
to anyone else.

<< 2.  Sometimes we have customers that are having damaged blob-files which
are not recognized by the repair command.  Thats quite bad cause you would
have to open each table and access every record to you see if the blob-error
appears... fixing is mostly done by simply "null-ing" the damaged field ...
sometimes it also worked to export and reimport the table to fix it ...  but
nulling a damaged field is a quite easier way. >>

The repair functionality *never* deletes data unless it violates the
structural or relational integrity of the table/database.  If you have BLOB
columns that contain *logically* corrupted BLOB data, then it is up to you
to fix that or delete, as necessary, *after* running the repair to correct
the structural integrity of the table/database.

Tim Young
Elevate Software
www.elevatesoft.com

Volker,

<< we always had such problems with elevate .. dont understand me wrong ..
we do not have such errors often .. but they exist. >>

Have you ever used the ElevateDB Server ?  If not, then that's why.

<< e.g. the SQLAnywhere-Database uses a BackLog to fix such errors by
re-processing the last commands you could  just unplug the computer and it
would fix it self and finish pending opertions... so yes it is possible to
use file-based databases on network-shares. >>

That is completely incorrect.   What you have there is SQL Anywhere using
the C/S model where the server process has exclusive access to the
database(s), and then you're storing the database(s) on a network share.
That is not anywhere near the same thing as using the file-sharing model in
ElevateDB where each application process on each machine is writing to the
same files.

<< Sure using the Database-Server-Process would mostly solve the issues ...
but our customers are having mostly 1~3 single computers ... and a nas-drive
... no way of using a server-process.... "Mrs. Marple please turn on your pc
i've to work ..."  >>

You're using a NAS appliance for storing the database ???  You're just
asking for trouble with such a configuration, especially is the OS being
used by the NAS device does not handle file-sharing protocols properly.  You
should use a proper Windows machine for storing your databases.

<< On my current point of view elevate misses some kind of automatically
fixing feature. >>

Your point of view is wrong.

<< Detecting unfinished write-operations and fixing that stuff. >>

ElevateDB *does* do that, but because of the way that the file-sharing model
works, there is no guarantee that *any* of the writes will make it to the
networked storage and on disk.  For *every single write*, ElevateDB writes
out a flag to the table header that indicates that the write is in progress,
writes out the changed data, and then clears this flag to indicate that the
write is complete.  If any session tries to read from the table and
encounters the write flag set, then an exception is raised and the table can
no longer be used until a repair is executed.

Tim Young
Elevate Software
www.elevatesoft.com

Volker,

<< So if something goes wrong log-file would know if something gone wrong ..
this Log-File should be stored seperatly from the database on another
location .. for example a second nas *G* .. so if the harddrive of NAS 'A'
dies the database could regenerate it self by using the log-replay from NAS
'B' .. and the other way round ...

well its a nice feature ... if the database gets corrupted it can be
re-created by the log-replay .. and if the log get's damaged it can be just
deleted ... if you store both on diffrent devices... in any constelation you
can just simple pull the power plug ... >>

Yes, and SQL Anywhere is running on a separate machine from the NAS, with
exclusive access to the database(s).   IOW, the very thing that you say that
you can't do with the ElevateDB Server, correct ?

Tim Young
Elevate Software
www.elevatesoft.com

Okay lets see .. you say its all about filesharing.
Using ElevateDB with Filesharing is a bad idea .. and customers having
issues should use the ElevateDB-Server to reduce issues.

please dont understand my comparison with sqlanywhere as grumble ... in our decision process we dicided us to use elevatedb.
i just wanted to clearify if there are any options to improve elevatedb to get more solid.

thx for that.