Icon View Thread

The following is the text of the current message along with any replies.
Messages 1 to 10 of 12 total
Thread Curious experience with #9217 error reading from table
Wed, Jul 29 2009 12:07 PMPermanent Link

"John Taylor"
I had an interesting experience this morning...

Using DBIsam 4.27 accessing a table on a networked computer from
my development machine.

The app has two forms that may access that table but never at the same time,
the forms are created as needed and never exist at the same time.  The forms
both
use Developer's express Quantum Grid (latest version).  One form could
access
the table no problem, the other *always* gave #9217 error reading from
table.

Repeated numerous times.  Used DBsys to verify the table, verify ok.  Same
problem.
Used dbsys to repair table, repair reported no errors.  Same problem
persisted.

Finally I rebooted the development system, *not* the network computer where
the table resides.  Magically the problem is gone.

BTW, I added some code in the exception handler to check the
EDBIsamEngineError's
OSErrorCode property, it was zero.  While all this was going on.

Does anyone know what to make of all this ?

It does not give me that 'warm fuzzy feeling' about things Frown

Thanks
John Taylor
Thu, Jul 30 2009 1:03 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

John,

<< Does anyone know what to make of all this ? >>

DBISAM uses straight-up Win32 API calls for reading files, and if the bytes
read does not equal the bytes expected to be read, then this error is
issued.  If working over a network link, then the most likely culprit is an
issue with the networking layers between the two machines.  Is this a
wireless network that you're using ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Thu, Jul 30 2009 1:57 PMPermanent Link

"John Taylor"
It is a wired network.

Also, one form never had the issue reading the table, it was the other form
that *always* generated the 9217.

Toggling back and forth, back and forth between these forms never showed the
problem in the one form, only
in the other.


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:C1CB41DB-0672-4C67-AC2E-6682B596A7F9@news.elevatesoft.com...
> John,
>
> << Does anyone know what to make of all this ? >>
>
> DBISAM uses straight-up Win32 API calls for reading files, and if the
> bytes read does not equal the bytes expected to be read, then this error
> is issued.  If working over a network link, then the most likely culprit
> is an issue with the networking layers between the two machines.  Is this
> a wireless network that you're using ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Fri, Jul 31 2009 12:14 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

John,

<< Also, one form never had the issue reading the table, it was the other
form that *always* generated the 9217.

Toggling back and forth, back and forth between these forms never showed
the problem in the one form, only in the other. >>

Do you have another network that you can try this on ?  If not, can you send
me what you're using so that I can test it here ?

Thanks,

--
Tim Young
Elevate Software
www.elevatesoft.com

Sat, Aug 1 2009 9:40 AMPermanent Link

"John Taylor"
Thanks Tim, but I cannot reproduce the issue anymore.

As I indicated in my original post, the problem went away after I rebooted
the development machine.

I also see more madexcept reports sent in from users of our legacy software
that uses DBIsam 3.30
indicating 9217's than I would expect.  But the situation I was describing
in my post was not with
that application, but the next incarnation under development using DBIsam 4

I actually have one prospective user of the legacy app which is dead in the
water with this issue
trying to access a table over his network, he's tried everything and I'm out
of suggestions for him.
He's repaired using dbsys, checked his network to no end, even deleted and
recreated new table,
scanned his hard drive for errors, removed av software, you name it but
still gets 9217 from one workstation


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:3E5E56E7-250E-4F81-A223-E7BFE66A784E@news.elevatesoft.com...
> John,
>
> << Also, one form never had the issue reading the table, it was the other
> form that *always* generated the 9217.
>
> Toggling back and forth, back and forth between these forms never showed
> the problem in the one form, only in the other. >>
>
> Do you have another network that you can try this on ?  If not, can you
> send me what you're using so that I can test it here ?
>
> Thanks,
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Mon, Aug 3 2009 12:41 PMPermanent Link

"John Taylor"
Here is a madexcept dump from the legacy software using DBIsam 3.30 received
this morning.
We are getting quite a few of these lately and it is difficult to believe
that all of these are due
to 'real' 9217 which the manual says should hardly every happen Frown

date/time         : 2009-08-02, 16:46:44, 821ms
computer name     : BOB-PC
user name         : BOB
operating system  : Windows NT New Service Pack 1 build 6001
system language   : English
system up time    : 4 hours 32 minutes
program up time   : 3 hours 2 minutes
processors        : 2x AMD Turion(tm) 64 X2 Mobile Technology TL-58
physical memory   : 873/1917 MB (free/total)
free disk space   : (CSmile96.73 GB
display mode      : 1280x800, 32 bit
process id        : $1500
allocated memory  : 123.95 MB
command line      : "C:\Program Files\Snappy Fax Version 4\sf4.exe" Snappy
Fax Version 4
executable        : sf4.exe
exec. date/time   : 2008-03-18 09:57
version           : 4.18.1.1
madExcept version : 2.7g
exception class   : EDBISAMEngineError
exception message : DBISAM Engine Error # 9217 Error reading from the table
'sfsentfaxes'.

main thread ($163c):
0061abe9 sf4.exe      DBISAMTb                  DbiError
005e02aa sf4.exe      dbisamen                  RaiseError
00615038 sf4.exe      dbisamen                  TBlobFile.GetBlock
00614d0f sf4.exe      dbisamen                  TBlobFile.GetNextFreeBlock
005e9b3a sf4.exe      dbisamen                  TDataTable.GetNextFreeBlock
005ee8a2 sf4.exe      dbisamen                  TDataCursor.GetNextFreeBlock
0061451c sf4.exe      dbisamen                  TBlobBuffer.Write
00604cd8 sf4.exe      dbisamen                  TDataCursor.FlushBlobBuffers
005fbdda sf4.exe      dbisamen                  TDataCursor.AppendRecord
0061e5ae sf4.exe      DBISAMTb                  TDBISAMDataSet.InternalPost
0058e9a1 sf4.exe      Db                   9675 TDataSet.CheckOperation
0058e618 sf4.exe      Db                   9532 TDataSet.Post
0061e631 sf4.exe      DBISAMTb                  TDBISAMDataSet.Post
00c89674 sf4.exe      main                 5164 TFmSF4Main.AddSentFile
"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:3E5E56E7-250E-4F81-A223-E7BFE66A784E@news.elevatesoft.com...
> John,
>
> << Also, one form never had the issue reading the table, it was the other
> form that *always* generated the 9217.
>
> Toggling back and forth, back and forth between these forms never showed
> the problem in the one form, only in the other. >>
>
> Do you have another network that you can try this on ?  If not, can you
> send me what you're using so that I can test it here ?
>
> Thanks,
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Tue, Aug 4 2009 2:09 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

John,

<< Thanks Tim, but I cannot reproduce the issue anymore.

As I indicated in my original post, the problem went away after I rebooted
the development machine. >>

That indicates that the issue is most likely environmental, especially if a
repair of the table in question comes up clean.

<< I also see more madexcept reports sent in from users of our legacy
software that uses DBIsam 3.30 indicating 9217's than I would expect.  But
the situation I was describing in my post was not with that application, but
the next incarnation under development using DBIsam 4 >>

DBISAM 3.x and 4.x are quite a bit different in some respects, and the same
in many others.  The main issue here is a situation where DBISAM is trying
to read X number of bytes from disk, and is getting back from the OS only Y
number of bytes.  This is caused by:

a) Environmental factors such as issues with the disk or network,

b) Corruption in the table that is causing one or more references to a
certain record, index page, or BLOB block number that is invalid because it
is beyond the beginning or end of the file, or

c) A situation where more than one application using DBISAM is accessing and
updating the same table, and one of the application is using a different
LargeFileSupport setting than the other application.

Those are the only three things that will cause such an error.  Are you
using large file support at all in your applications ?

<< I actually have one prospective user of the legacy app which is dead in
the water with this issue trying to access a table over his network, he's
tried everything and I'm out of suggestions for him. >>

And what about locally ?  Can he run the same application with the same
tables locally ?  Also, when the application is run over the network, how
many users are accessing it at the time of the error ?  Any updating going
on ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Mon, Aug 10 2009 10:13 AMPermanent Link

"John Taylor"
Tim,

Thanks for the follow up on this...

We get several 9217's a week, it seems.

All from our legacy application build with Delphi 5 and DBIsam 3.30
no large file support. (Did DBIsam 3 even have large file support, can't
remember)

Sometimes on a local table sometimes on a network table, it seems to be a
mixed
bag.


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:57910413-CD73-4DCC-9994-38B8233B24C0@news.elevatesoft.com...
> John,
>
> << Thanks Tim, but I cannot reproduce the issue anymore.
>
> As I indicated in my original post, the problem went away after I rebooted
> the development machine. >>
>
> That indicates that the issue is most likely environmental, especially if
> a repair of the table in question comes up clean.
>
> << I also see more madexcept reports sent in from users of our legacy
> software that uses DBIsam 3.30 indicating 9217's than I would expect.  But
> the situation I was describing in my post was not with that application,
> but the next incarnation under development using DBIsam 4 >>
>
> DBISAM 3.x and 4.x are quite a bit different in some respects, and the
> same in many others.  The main issue here is a situation where DBISAM is
> trying to read X number of bytes from disk, and is getting back from the
> OS only Y number of bytes.  This is caused by:
>
> a) Environmental factors such as issues with the disk or network,
>
> b) Corruption in the table that is causing one or more references to a
> certain record, index page, or BLOB block number that is invalid because
> it is beyond the beginning or end of the file, or
>
> c) A situation where more than one application using DBISAM is accessing
> and updating the same table, and one of the application is using a
> different LargeFileSupport setting than the other application.
>
> Those are the only three things that will cause such an error.  Are you
> using large file support at all in your applications ?
>
> << I actually have one prospective user of the legacy app which is dead in
> the water with this issue trying to access a table over his network, he's
> tried everything and I'm out of suggestions for him. >>
>
> And what about locally ?  Can he run the same application with the same
> tables locally ?  Also, when the application is run over the network, how
> many users are accessing it at the time of the error ?  Any updating going
> on ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Mon, Aug 10 2009 2:19 PMPermanent Link

Tim Young [Elevate Software]

Elevate Software, Inc.

Avatar

Email timyoung@elevatesoft.com

John,

<< All from our legacy application build with Delphi 5 and DBIsam 3.30 no
large file support. (Did DBIsam 3 even have large file support, can't
remember) >>

Yes, but with DBISAM 3.x you had to recompile the source code to enable it.

<< Sometimes on a local table sometimes on a network table, it seems to be a
mixed bag. >>

And you can never reproduce the issue in a controlled environment ?

--
Tim Young
Elevate Software
www.elevatesoft.com

Tue, Aug 11 2009 5:02 AMPermanent Link

"John Taylor"
Never have been able to reproduce it here.



"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote in message
news:2226337E-EC36-4053-A856-31A301C2ABC9@news.elevatesoft.com...
> John,
>
> << All from our legacy application build with Delphi 5 and DBIsam 3.30 no
> large file support. (Did DBIsam 3 even have large file support, can't
> remember) >>
>
> Yes, but with DBISAM 3.x you had to recompile the source code to enable
> it.
>
> << Sometimes on a local table sometimes on a network table, it seems to be
> a mixed bag. >>
>
> And you can never reproduce the issue in a controlled environment ?
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>
Page 1 of 2Next Page »
Jump to Page:  1 2
Image