Dominique


CAN'T and won't. It can't because it has to be exclusive and it won't because Tim won't let it. Think about it for a moment. The repair software goes along, finds a corrupt index and fixes it just as someone is inserting a new record. Result the indices are more corrupt now than they were before. Or it finds an erroneous pointer in a blob and as its trying to sort that out someone is writing a large memo field using the corrupt pointers.

As Robert says try it in DBSys. Open a reasonably large table, open another copy of DBSys open the same table and now try and run repair on the table. You won't be able to.

Roy Lambert [Team Elevate]

Roy Lambert wrote:
> The repair
> software goes along, finds a corrupt index and fixes it just as
> someone is inserting a new record. Result the indices are more
> corrupt now than they were before. Or it finds an erroneous pointer
> in a blob and as its trying to sort that out someone is writing a
> large memo field using the corrupt pointers.

Yes, I was kind of hoping this was the cause, but since a table that's
being repaired won't be accessed by another app, I'll just have to look
further.

Dominique


Can you give us a bit more information eg what is the corruption: indices, blob offsets or what? Is it fileserver, client server a mixture? Are the two apps running on the same PC or different PCs?

Roy Lambert

Dominique,

<< Is this also the case in version 3? Tim? >>

Yes, this has always been the case with all versions of DBISAM.

--
Tim Young
Elevate Software
www.elevatesoft.com

Dom,

<< After quite some years of experience with DBISAM V3, I keep noticing that
users who run my app on a system that has two apps accessing the
same DB simultaneously, suffer more data corruption than others. >>

How is the database set up ?  Peer-to-peer, or is there an actual file
server ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim Young [Elevate Software] wrote:
> Yes, this has always been the case with all versions of DBISAM.

Excellent. Many thanks.

Roy Lambert wrote:
> Can you give us a bit more information eg what is the corruption:
> indices, blob offsets or what? Is it fileserver, client server a
> mixture? Are the two apps running on the same PC or different PCs?

I wish I could give more details about the corruption type. It happens
very irregularly, but when it happens, it's on PCs running the two apps
simultaneously (and also accessing the tables simultaneously). The
system carries out a repair by itself, but doesn't spew out any details
-- only a message when the repair was not successful.

Many thanks for your assistance, as usual, but I do understand the info
I'm giving just isn't sufficient. I'll have to diagnose further as it
occurs.

Tim Young [Elevate Software] wrote:
> How is the database set up ?  Peer-to-peer, or is there an actual
> file server ?

One app on the PC is a table synchronization server I wrote from
scratch, communicating with other apps on the LAN and WAN. The other
app is a client app that accesses the same tables directly.

(the other apps on the LAN and WAN are the same client app, but they
synchronize their local tables through communication with this
synchronization server)

So, basically, where the problem occurs (occasionally) there are two
apps accessing the same tables simultaneously, locally, on one single
PC. I want to mention that most of the time this works perfectly. It's
just these exceptions that make me curious as to find the cause.

Maybe V4 (which I use in another unrelated app, btw) handles this
inter-app session stuff better? Just asking.

Hi Dominique,

A few thoughts:

1) Do both applications have the same DBISam Build in them? I know I got
into trouble with version 4 (same application) if one user was running
the application using say DBISam 4.24b1 and another one using DBISam 4.24b2.

2) Does this happen at various locations or just this one location? My
thought is maybe it's not the two different apps accessing the same
tables but something else on the network (network problems, flakey HDD
on the server, etc) - and it's just coincidense that it's happening at
this site where you have two different apps accessing the same DB.

Hope this helps...

Adam.

Adam H. wrote:
> 1) Do both applications have the same DBISam Build in them?

Yes, they do.

> 2) Does this happen at various locations or just this one location?

Various locations.

It's so sporadic that it's hard to track. Maybe there are other
elements I haven't taken into consideration yet.

Many thanks!