I'm having an interesting problem that I've never seen before. When I verify a table, I
get an error message about 75% of the way through that says "The connection to the server
has been interrupted or timed out and needs to be reconnected to proceed. Would you like
to continue with the automatic reconnection?" I choose Yes and the error fires again at 100%.

When I repair, I get that same error message at 100% and then an error log that says it
found a problem with the record id field on every record. (I think it's every record -
haven't really counted.) It appears to be assigning a new record id during the repair. The
thing is, after repairing, the same thing still happens on the Verify, and if I Repair
again, I'll get that same repair behavior.

I've tried the verify on a few tables. It doesn't happen on all of them, but when it does
happen, it seems to stop the first time at 75-76%, and then again at 100%. I'm kind of
afraid to mess with the Repair any more. :-/ Any ideas?

I upgraded from dbisam v3 last week. I'm now at 4.24 build 1 and I changed the default
port for v4, in case that info is of use. I'm using Delphi 5. (Purchased and installed
Delphi 2006 recently and so far I hate it, but the plan is to upgrade sometime soon.)

Sue,

<< I'm having an interesting problem that I've never seen before. When I
verify a table, I get an error message about 75% of the way through that
says "The connection to the server has been interrupted or timed out and
needs to be reconnected to proceed. Would you like
to continue with the automatic reconnection?" I choose Yes and the error
fires again at 100%. >>

Are you using DBSYS or is this your own code ?

<< When I repair, I get that same error message at 100% and then an error
log that says it found a problem with the record id field on every record.
(I think it's every record - haven't really counted.) It appears to be
assigning a new record id during the repair. The thing is, after repairing,
the same thing still happens on the Verify, and if I Repair again, I'll get
that same repair behavior. >>

So, the Verify doesn't find any problem with the record ID field, but the
Repair does ?  If so, could you send me the table that you're seeing this
with (timyoung@elevatesoft.com) ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Sue,

What version are you using? I had the same problem and I was using
V4.21xxx. It was a remote connection via internet to a database and
trying to verify/repair 110 tables sucked because it would constantly
say the connection was interrupted (it seemed like it would do this once
every few tables, which meant I had to reconnect over 30 times during
the process).

Also, I had the same exact problems with the verify/repair behavior; it
wasn't every record that had a problem, but there were a lot of them.
When I updated to the latest version, the problem with verify/repair
behavior went away. I don't know if the connection/reconnection problem
went away because I finally gave up and connected to the remote site and
used pcAnywhere to download the database files locally.

Tim, all of this happened using DBSys.

Regards,

Jason Lee


Tim Young [Elevate Software] wrote:
> Sue,
>
> << I'm having an interesting problem that I've never seen before. When I
> verify a table, I get an error message about 75% of the way through that
> says "The connection to the server has been interrupted or timed out and
> needs to be reconnected to proceed. Would you like
> to continue with the automatic reconnection?" I choose Yes and the error
> fires again at 100%. >>
>
> Are you using DBSYS or is this your own code ?
>
> << When I repair, I get that same error message at 100% and then an error
> log that says it found a problem with the record id field on every record.
> (I think it's every record - haven't really counted.) It appears to be
> assigning a new record id during the repair. The thing is, after repairing,
> the same thing still happens on the Verify, and if I Repair again, I'll get
> that same repair behavior. >>
>
> So, the Verify doesn't find any problem with the record ID field, but the
> Repair does ?  If so, could you send me the table that you're seeing this
> with (timyoung@elevatesoft.com) ?
>

Sue,

Sorry, I must have spaced right over your version info in your post.
I'll give my scenario a try with the latest version and see if I can
duplicate the problems I had.

It was very frustrating because it seems like it kept randomly reporting
different tables as being corrupt. When I tested the tables locally
(local session in DBSys) they were fine. Also, the disconnect/reconnect
problem was weird too.

Details:
V4.21 DBSys with pinging every 60 secs and compression set to highest,
Delphi 7, WinXP Pro server across DSL connection to WinXP Pro client

Will report back as soon as I know.

Regards,

Jason Lee


Jason Lee wrote:
> Sue,
>
> What version are you using? I had the same problem and I was using
> V4.21xxx. It was a remote connection via internet to a database and

I figured out that I get the weird verify/repair behavior only when I run dbsys from a
win2k machine. All is well when run from XP, or from 2003 server.

Migrated to new server hardware yesterday. My verify/repair problem seems to have
vanished. Shrug. I do rather like it when problems fix themselves though.

Sue,

<< Migrated to new server hardware yesterday. My verify/repair problem seems
to have vanished. Shrug. I do rather like it when problems fix themselves
though. >>

So, same OS (Win2k), but different result with new hardware ?  If so, then
sounds like a hard drive on the fritz or heading that way.

--
Tim Young
Elevate Software
www.elevatesoft.com

Same OS on the new server (2003); workstation hasn't changed. The old server had a RAID 5
array, as does the new one, so hard drive issues don't seem that likely a culprit to me.
Before I get rid of the old server, I may have to fire it up once more just to see if that
problem is still there. Too weird.

Sue,

<< Same OS on the new server (2003); workstation hasn't changed. The old
server had a RAID 5 array, as does the new one, so hard drive issues don't
seem that likely a culprit to me. Before I get rid of the old server, I may
have to fire it up once more just to see if that
problem is still there. Too weird. >>

Hmm, indeed.  We use 2003 here and it has been stellar, no problems at all.

--
Tim Young
Elevate Software
www.elevatesoft.com