Oh ok, thanks Rob good to know for future reference too...

ooops, sorry meant Roy...

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:F87C75DA-817F-4141-9F1D-D306749B7DFB@news.elevatesoft.com...
> ClockOn
>
>
> Just that it could be down to network cards or cabling or even PC
> configuration.
>
> Roy Lambert
>

Before choosing DBISam, I developed a small test app to evaluate DBISam and
2 other DB Engine products. Among other things, I wanted to find out what it
would take to crash or corrupt the tables.  The App would programmatically
insert a couple hundred thousand records with random data, I would time it
for performance. Other times, during the updates I would pull the network
cable (tried to simulate loss of network connectivity), shut down
workstation/ server, cut power to workstation/ server etc. Anything that
would corrupt the darn thing.

I found that pulling the workstations network cable or cutting power to the
workstation often corrupted the table under local sessions but never under
remote connections. With remote sessions, when I pulled the cable, the
DBISam server would gracefully drop the connection to that workstation while
all other network users remained unaffected by this and could continue as
usual. Local sessions mostly affected everyone else connected to the DB. The
tables never corrupted when there were no write operations involved.

Although this was done on DBISam V3 and Windows ME/ Windows 2000, maybe its
still quite relevant. I think the problem is more likely to be closer to the
server side. Probably something abnormally terminating or interfering with
the db server operation during an update but before a commit/ flush buffer.
Quite curious to know what it is Clockon, if you do find the problem pls
post back.



--
Regards
Gregory Sebastian

Thanks Gregory. I have more details now. I've had the error come up again and completed a verify and found it's returning an blob offset error.

Now the cause may be our DBISAM service because we are not using the stock version we have built a custom version. Which could be where the offset is coming from but not sure yet.

I haven't eliminated the possibility of the computer jus yet because this does sound like it is the usual cause of the corruption. But ill see what I can find in our service...

<< Thanks Gregory. I have more details now. I've had the error come up again
and completed a verify and found it's returning an blob offset error. >>

What version of DBISAM are you using ?  Also, are you using optimistic or
pessimistic record locking ?

--
Tim Young
Elevate Software
www.elevatesoft.com

optimistic and 4.22 Build 6 im pretty sure...

Version 4.26 build 3

<< optimistic and 4.22 Build 6 im pretty sure... >>

The optimistic record locking is the issue if you're seeing BLOB errors.
The 4.28 and higher releases have a new BLOB design that fixes this problem,
but per the release notes, you cannot mix and match the versions:

"There is a new design for the BLOB reading/writing that is not compatible
with 4.27 or earlier. Therefore, it is extremely important that you do not
mix DBISAM 4.28 applications with DBISAM 4.27 or earlier applications.
Mixing the two versions can cause improper truncation of BLOB data, and that
includes using a 4.27 application on any data that has been updated by
DBISAM 4.28, even if it is not concurrently. The issue is that 4.27 and
earlier versions recylcle BLOB blocks on a per-block basis, whereas 4.28 and
higher versions recycle BLOB blocks on a per-row basis."

This applies to any application that directly access the databases.  For
example, if your application uses the DBISAM Database Server only, then you
would only need to update your DBISAM Database Server to 4.28 or higher in
order to fix this issue.

The other option is to switch to pessimistic record locking instead, and
then you will be able to stay at 4.26.

--
Tim Young
Elevate Software
www.elevatesoft.com

thanks Tim good to know, we have now upgraded to the latest version (4.3), ill keep you posted...