Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 10 of 12 total |
Curious experience with #9217 error reading from table |
Wed, Jul 29 2009 12:07 PM | Permanent 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 Thanks John Taylor |
Thu, Jul 30 2009 1:03 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 PM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent 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 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 : (C96.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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. 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 AM | Permanent 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 2 | Next Page » | |
Jump to Page: 1 2 |
This web page was last updated on Tuesday, September 17, 2024 at 04:19 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |