Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM Client/Server » View Thread |
Messages 1 to 8 of 8 total |
DBISAM Error 9217 - Version 4.26 Build 3 |
Tue, Feb 2 2010 12:53 PM | Permanent Link |
Michael Gonyea | Hi folks,
Having some trouble with DBISAM that I can't quite track down. Here's some background on our development environment: Delphi 2007 DBISAM Version 4.26 Build 3 madExcept We have two separate applications that access a local table. At any point during the application, exe #2 will add/remove/change records in the local table, which exe #1 uses in a read-only fashion (i.e. exe #1 only performs "locates" on the table, but never adds/changes/deletes records). Here is an excerpt from one of the madExcept reports, along with an explanation of what was happening with our 2 applications: exception class : EDBISAMEngineError exception message : DBISAM Engine Error # 9217 Error reading from the table or backup file 'PinnedWagons'. Main ($208): 0087e3fd RemoteBuyer.exe dbisamtb DBISAMError 007e6542 RemoteBuyer.exe dbisamen TDataEngine.RaiseError 00813a0a RemoteBuyer.exe dbisamen TDataCursor.CheckError 00885ea3 RemoteBuyer.exe dbisamtb TDBISAMDataSet.GetRecord 004f66f9 RemoteBuyer.exe DB TDataSet.Resync 008881fe RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate 00954f2e RemoteBuyer.exe MainForm TClockTestForm.GridProductsSelectCell 0067b92e RemoteBuyer.exe Grids TCustomDrawGrid.SelectCell 00678e1e RemoteBuyer.exe Grids TCustomGrid.MoveCurrent 00678daa RemoteBuyer.exe Grids TCustomGrid.MoveAnchor 00677e8a RemoteBuyer.exe Grids DoChange 00677fb2 RemoteBuyer.exe Grids TCustomGrid.ChangeSize 0067ac88 RemoteBuyer.exe Grids TCustomGrid.SetRowCount 00681308 RemoteBuyer.exe Aligrid TStringAlignGrid.RemoveRow 009689cd RemoteBuyer.exe pinnedList TPinned.delete 00967298 RemoteBuyer.exe dtmdlRB TdmRemoteBuyer.PinnedWagonsChanged 0093836a RemoteBuyer.exe TCPDataServer TDataServerRecvThread.RunCommand Explanation: EXE #2 (our "data service") deletes a records in the local "PinnedWagons" table and then sends a message via TCP to EXE #1 which triggers a "PinnedWagonsChanged" procedure to run in EXE #1. The "TPinned.delete" method removes an item from a custom TList object, then proceeds to visually remove row <x> from a non-data-aware grid. After the row is removed, we trigger a manual "re-select a grid line" which in turn performs a lookup on the local "PinnedWagons" table to obtain some record info to be displayed on the screen (size, colour, item code, etc.) At this point, the exception is triggered. Any ideas? I have more examples if that helps. Thank you in advance! |
Tue, Feb 2 2010 2:06 PM | Permanent Link |
"Raul" | Error 9217 often is due to a corrupted table or some file level interference like AV: - have you done a repair? - reboot the computer just to be safe and also turn off AV ? Is the error reproducible ? Raul "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message news:ED076E32-9BB6-43A0-874F-84AA4B6F2EA0@news.elevatesoft.com... > Hi folks, > > Having some trouble with DBISAM that I can't quite track down. Here's > some background on our development environment: > > Delphi 2007 > DBISAM Version 4.26 Build 3 > madExcept > > We have two separate applications that access a local table. At any point > during the application, exe #2 will add/remove/change records in the local > table, which exe #1 uses in a read-only fashion (i.e. exe #1 only performs > "locates" on the table, but never adds/changes/deletes records). Here is > an excerpt from one of the madExcept reports, along with an explanation of > what was happening with our 2 applications: > > exception class : EDBISAMEngineError > exception message : DBISAM Engine Error # 9217 Error reading from the > table or backup file 'PinnedWagons'. > > Main ($208): > 0087e3fd RemoteBuyer.exe dbisamtb DBISAMError > 007e6542 RemoteBuyer.exe dbisamen TDataEngine.RaiseError > 00813a0a RemoteBuyer.exe dbisamen TDataCursor.CheckError > 00885ea3 RemoteBuyer.exe dbisamtb TDBISAMDataSet.GetRecord > 004f66f9 RemoteBuyer.exe DB TDataSet.Resync > 008881fe RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate > 00954f2e RemoteBuyer.exe MainForm TClockTestForm.GridProductsSelectCell > 0067b92e RemoteBuyer.exe Grids TCustomDrawGrid.SelectCell > 00678e1e RemoteBuyer.exe Grids TCustomGrid.MoveCurrent > 00678daa RemoteBuyer.exe Grids TCustomGrid.MoveAnchor > 00677e8a RemoteBuyer.exe Grids DoChange > 00677fb2 RemoteBuyer.exe Grids TCustomGrid.ChangeSize > 0067ac88 RemoteBuyer.exe Grids TCustomGrid.SetRowCount > 00681308 RemoteBuyer.exe Aligrid TStringAlignGrid.RemoveRow > 009689cd RemoteBuyer.exe pinnedList TPinned.delete > 00967298 RemoteBuyer.exe dtmdlRB TdmRemoteBuyer.PinnedWagonsChanged > 0093836a RemoteBuyer.exe TCPDataServer TDataServerRecvThread.RunCommand > > Explanation: > > EXE #2 (our "data service") deletes a records in the local "PinnedWagons" > table and then sends a message via TCP to EXE #1 which triggers a > "PinnedWagonsChanged" procedure to run in EXE #1. The "TPinned.delete" > method removes an item from a custom TList object, then proceeds to > visually remove row <x> from a non-data-aware grid. After the row is > removed, we trigger a manual "re-select a grid line" which in turn > performs a lookup on the local "PinnedWagons" table to obtain some record > info to be displayed on the screen (size, colour, item code, etc.) At > this point, the exception is triggered. > > Any ideas? I have more examples if that helps. > > Thank you in advance! > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4828 (20100202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4829 (20100202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
Tue, Feb 2 2010 2:36 PM | Permanent Link |
Michael Gonyea | Hi Raul,
Thanks for the quick reply. When the main program (exe #1) starts up, it goes through a Verify/Repair sequence on all of the local tables to ensure the tables/indexes are not corrupted. The error is somewhat reproducible; however, seems to happen more often during times where exe #1 sets/resets a filter on the local table, or when performing a "Locate" after a record has very recently been deleted by exe #2. Here is another example from madExcept: exception class : EDBISAMEngineError exception message : DBISAM Engine Error # 9217 Error reading from the table or backup file 'PinnedWagons'. Main ($62c): 0087e3fd +011 RemoteBuyer.exe dbisamtb DBISAMError 007e6542 +07e RemoteBuyer.exe dbisamen TDataEngine.RaiseError 007ecf02 +08a RemoteBuyer.exe dbisamen TEngineFile.Read 007ed082 +032 RemoteBuyer.exe dbisamen TEngineFile.Seek 007ee16a +176 RemoteBuyer.exe dbisamen TBufferedFile.ReadBuffers 007ede18 +150 RemoteBuyer.exe dbisamen TBufferedFile.GetBuffer 007fb0ca +01a RemoteBuyer.exe dbisamen TDataTable.GetRecord 007ff65b +027 RemoteBuyer.exe dbisamen TDataCursor.GetRecord 0080b39e +032 RemoteBuyer.exe dbisamen TDataCursor.RefreshCurrentRecord 00813772 +02a RemoteBuyer.exe dbisamen TDataCursor.RepositionCurrentRecord 007ff013 +027 RemoteBuyer.exe dbisamen TDataCursor.CheckForCursorChanges 007ff03a +01e RemoteBuyer.exe dbisamen TDataCursor.CheckForChangeDetection 0080bc8b +19f RemoteBuyer.exe dbisamen TDataCursor.Locate 00887fbe +3ee RemoteBuyer.exe dbisamtb TDBISAMDataSet.LocateRecord 008881d9 +025 RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate 009532dd +31d RemoteBuyer.exe MainForm 3379 +51 TClockTestForm.findFlowerImage The "findFlowerImage" attempts to "Locate" a record in the local PinnedWagons table based on item code, line #, etc. and then uses some fields from PinnedWagons to locate an exact picture for the product (e.g. red rose vs. fire-and-ice rose, etc.) in a separate images table. On 10-02-02 11:06 AM, Raul wrote: > > Error 9217 often is due to a corrupted table or some file level > interference like AV: > > - have you done a repair? > > - reboot the computer just to be safe and also turn off AV ? > > Is the error reproducible ? > > Raul > > > "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message > news:ED076E32-9BB6-43A0-874F-84AA4B6F2EA0@news.elevatesoft.com... >> Hi folks, >> >> Having some trouble with DBISAM that I can't quite track down. Here's >> some background on our development environment: >> >> Delphi 2007 >> DBISAM Version 4.26 Build 3 >> madExcept >> >> We have two separate applications that access a local table. At any >> point during the application, exe #2 will add/remove/change records in >> the local table, which exe #1 uses in a read-only fashion (i.e. exe #1 >> only performs "locates" on the table, but never adds/changes/deletes >> records). Here is an excerpt from one of the madExcept reports, along >> with an explanation of what was happening with our 2 applications: >> >> exception class : EDBISAMEngineError >> exception message : DBISAM Engine Error # 9217 Error reading from the >> table or backup file 'PinnedWagons'. >> >> Main ($208): >> 0087e3fd RemoteBuyer.exe dbisamtb DBISAMError >> 007e6542 RemoteBuyer.exe dbisamen TDataEngine.RaiseError >> 00813a0a RemoteBuyer.exe dbisamen TDataCursor.CheckError >> 00885ea3 RemoteBuyer.exe dbisamtb TDBISAMDataSet.GetRecord >> 004f66f9 RemoteBuyer.exe DB TDataSet.Resync >> 008881fe RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate >> 00954f2e RemoteBuyer.exe MainForm TClockTestForm.GridProductsSelectCell >> 0067b92e RemoteBuyer.exe Grids TCustomDrawGrid.SelectCell >> 00678e1e RemoteBuyer.exe Grids TCustomGrid.MoveCurrent >> 00678daa RemoteBuyer.exe Grids TCustomGrid.MoveAnchor >> 00677e8a RemoteBuyer.exe Grids DoChange >> 00677fb2 RemoteBuyer.exe Grids TCustomGrid.ChangeSize >> 0067ac88 RemoteBuyer.exe Grids TCustomGrid.SetRowCount >> 00681308 RemoteBuyer.exe Aligrid TStringAlignGrid.RemoveRow >> 009689cd RemoteBuyer.exe pinnedList TPinned.delete >> 00967298 RemoteBuyer.exe dtmdlRB TdmRemoteBuyer.PinnedWagonsChanged >> 0093836a RemoteBuyer.exe TCPDataServer TDataServerRecvThread.RunCommand >> >> Explanation: >> >> EXE #2 (our "data service") deletes a records in the local >> "PinnedWagons" table and then sends a message via TCP to EXE #1 which >> triggers a "PinnedWagonsChanged" procedure to run in EXE #1. The >> "TPinned.delete" method removes an item from a custom TList object, >> then proceeds to visually remove row <x> from a non-data-aware grid. >> After the row is removed, we trigger a manual "re-select a grid line" >> which in turn performs a lookup on the local "PinnedWagons" table to >> obtain some record info to be displayed on the screen (size, colour, >> item code, etc.) At this point, the exception is triggered. >> >> Any ideas? I have more examples if that helps. >> >> Thank you in advance! >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4828 (20100202) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4829 (20100202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > |
Tue, Feb 2 2010 7:29 PM | Permanent Link |
"Raul" | Silly question but are you refreshing the table in app #1 after the delete takes place ? How about closing and reopening the table in app #1 before doing the locate - you should not need to but just to see if it problem happens then as well. Also any chance of trying it with latest dbisam version (4.29) - to see if it might already be fixed ? Raul "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message news:D4A7E8DB-4950-415E-B9EA-EA721CBF8C1D@news.elevatesoft.com... > Hi Raul, > > Thanks for the quick reply. > > When the main program (exe #1) starts up, it goes through a Verify/Repair > sequence on all of the local tables to ensure the tables/indexes are not > corrupted. > > The error is somewhat reproducible; however, seems to happen more often > during times where exe #1 sets/resets a filter on the local table, or when > performing a "Locate" after a record has very recently been deleted by exe > #2. Here is another example from madExcept: > > exception class : EDBISAMEngineError > exception message : DBISAM Engine Error # 9217 Error reading from the > table or backup file 'PinnedWagons'. > > Main ($62c): > 0087e3fd +011 RemoteBuyer.exe dbisamtb DBISAMError > 007e6542 +07e RemoteBuyer.exe dbisamen TDataEngine.RaiseError > 007ecf02 +08a RemoteBuyer.exe dbisamen TEngineFile.Read > 007ed082 +032 RemoteBuyer.exe dbisamen TEngineFile.Seek > 007ee16a +176 RemoteBuyer.exe dbisamen > TBufferedFile.ReadBuffers > 007ede18 +150 RemoteBuyer.exe dbisamen TBufferedFile.GetBuffer > 007fb0ca +01a RemoteBuyer.exe dbisamen TDataTable.GetRecord > 007ff65b +027 RemoteBuyer.exe dbisamen TDataCursor.GetRecord > 0080b39e +032 RemoteBuyer.exe dbisamen TDataCursor.RefreshCurrentRecord > 00813772 +02a RemoteBuyer.exe dbisamen TDataCursor.RepositionCurrentRecord > 007ff013 +027 RemoteBuyer.exe dbisamen TDataCursor.CheckForCursorChanges > 007ff03a +01e RemoteBuyer.exe dbisamen TDataCursor.CheckForChangeDetection > 0080bc8b +19f RemoteBuyer.exe dbisamen TDataCursor.Locate > 00887fbe +3ee RemoteBuyer.exe dbisamtb TDBISAMDataSet.LocateRecord > 008881d9 +025 RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate > 009532dd +31d RemoteBuyer.exe MainForm 3379 +51 > TClockTestForm.findFlowerImage > > The "findFlowerImage" attempts to "Locate" a record in the local > PinnedWagons table based on item code, line #, etc. and then uses some > fields from PinnedWagons to locate an exact picture for the product (e.g. > red rose vs. fire-and-ice rose, etc.) in a separate images table. > > > On 10-02-02 11:06 AM, Raul wrote: >> >> Error 9217 often is due to a corrupted table or some file level >> interference like AV: >> >> - have you done a repair? >> >> - reboot the computer just to be safe and also turn off AV ? >> >> Is the error reproducible ? >> >> Raul >> >> >> "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message >> news:ED076E32-9BB6-43A0-874F-84AA4B6F2EA0@news.elevatesoft.com... >>> Hi folks, >>> >>> Having some trouble with DBISAM that I can't quite track down. Here's >>> some background on our development environment: >>> >>> Delphi 2007 >>> DBISAM Version 4.26 Build 3 >>> madExcept >>> >>> We have two separate applications that access a local table. At any >>> point during the application, exe #2 will add/remove/change records in >>> the local table, which exe #1 uses in a read-only fashion (i.e. exe #1 >>> only performs "locates" on the table, but never adds/changes/deletes >>> records). Here is an excerpt from one of the madExcept reports, along >>> with an explanation of what was happening with our 2 applications: >>> >>> exception class : EDBISAMEngineError >>> exception message : DBISAM Engine Error # 9217 Error reading from the >>> table or backup file 'PinnedWagons'. >>> >>> Main ($208): >>> 0087e3fd RemoteBuyer.exe dbisamtb DBISAMError >>> 007e6542 RemoteBuyer.exe dbisamen TDataEngine.RaiseError >>> 00813a0a RemoteBuyer.exe dbisamen TDataCursor.CheckError >>> 00885ea3 RemoteBuyer.exe dbisamtb TDBISAMDataSet.GetRecord >>> 004f66f9 RemoteBuyer.exe DB TDataSet.Resync >>> 008881fe RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate >>> 00954f2e RemoteBuyer.exe MainForm TClockTestForm.GridProductsSelectCell >>> 0067b92e RemoteBuyer.exe Grids TCustomDrawGrid.SelectCell >>> 00678e1e RemoteBuyer.exe Grids TCustomGrid.MoveCurrent >>> 00678daa RemoteBuyer.exe Grids TCustomGrid.MoveAnchor >>> 00677e8a RemoteBuyer.exe Grids DoChange >>> 00677fb2 RemoteBuyer.exe Grids TCustomGrid.ChangeSize >>> 0067ac88 RemoteBuyer.exe Grids TCustomGrid.SetRowCount >>> 00681308 RemoteBuyer.exe Aligrid TStringAlignGrid.RemoveRow >>> 009689cd RemoteBuyer.exe pinnedList TPinned.delete >>> 00967298 RemoteBuyer.exe dtmdlRB TdmRemoteBuyer.PinnedWagonsChanged >>> 0093836a RemoteBuyer.exe TCPDataServer TDataServerRecvThread.RunCommand >>> >>> Explanation: >>> >>> EXE #2 (our "data service") deletes a records in the local >>> "PinnedWagons" table and then sends a message via TCP to EXE #1 which >>> triggers a "PinnedWagonsChanged" procedure to run in EXE #1. The >>> "TPinned.delete" method removes an item from a custom TList object, >>> then proceeds to visually remove row <x> from a non-data-aware grid. >>> After the row is removed, we trigger a manual "re-select a grid line" >>> which in turn performs a lookup on the local "PinnedWagons" table to >>> obtain some record info to be displayed on the screen (size, colour, >>> item code, etc.) At this point, the exception is triggered. >>> >>> Any ideas? I have more examples if that helps. >>> >>> Thank you in advance! >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4828 (20100202) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4829 (20100202) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4829 (20100202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > __________ Information from ESET NOD32 Antivirus, version of virus signature database 4829 (20100202) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com |
Wed, Feb 3 2010 10:28 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Michael,
<< We have two separate applications that access a local table. At any point during the application, exe #2 will add/remove/change records in the local table, which exe #1 uses in a read-only fashion (i.e. exe #1 only performs "locates" on the table, but never adds/changes/deletes records). >> Are either of the applications compiled with the TDBISAMEngine.LargeFileSupport property set to True ? If so, are they *both* set to the same setting ? -- Tim Young Elevate Software www.elevatesoft.com |
Wed, Feb 3 2010 12:33 PM | Permanent Link |
Michael Gonyea | Hi Raul,
No, we don't explicitly refresh the table after the delete takes place. I will add a refresh in exe #1 and test that today. For testing, I will be able to open and close the table, but in production, exe #1 performs lookups regularly on this table, including when end-users scroll through the records to view product manually, so closing/re-opening a table after a delete might interfere with the end-users' experience. I will have to get approval from my customer first before upgrading to version 4.29, but I think that's a good idea! On 10-02-02 4:29 PM, Raul wrote: > > Silly question but are you refreshing the table in app #1 after the > delete takes place ? > > How about closing and reopening the table in app #1 before doing the > locate - you should not need to but just to see if it problem happens > then as well. > > Also any chance of trying it with latest dbisam version (4.29) - to see > if it might already be fixed ? > > Raul > > > > "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message > news:D4A7E8DB-4950-415E-B9EA-EA721CBF8C1D@news.elevatesoft.com... >> Hi Raul, >> >> Thanks for the quick reply. >> >> When the main program (exe #1) starts up, it goes through a >> Verify/Repair sequence on all of the local tables to ensure the >> tables/indexes are not corrupted. >> >> The error is somewhat reproducible; however, seems to happen more >> often during times where exe #1 sets/resets a filter on the local >> table, or when performing a "Locate" after a record has very recently >> been deleted by exe #2. Here is another example from madExcept: >> >> exception class : EDBISAMEngineError >> exception message : DBISAM Engine Error # 9217 Error reading from the >> table or backup file 'PinnedWagons'. >> >> Main ($62c): >> 0087e3fd +011 RemoteBuyer.exe dbisamtb DBISAMError >> 007e6542 +07e RemoteBuyer.exe dbisamen TDataEngine.RaiseError >> 007ecf02 +08a RemoteBuyer.exe dbisamen TEngineFile.Read >> 007ed082 +032 RemoteBuyer.exe dbisamen TEngineFile.Seek >> 007ee16a +176 RemoteBuyer.exe dbisamen TBufferedFile.ReadBuffers >> 007ede18 +150 RemoteBuyer.exe dbisamen TBufferedFile.GetBuffer >> 007fb0ca +01a RemoteBuyer.exe dbisamen TDataTable.GetRecord >> 007ff65b +027 RemoteBuyer.exe dbisamen TDataCursor.GetRecord >> 0080b39e +032 RemoteBuyer.exe dbisamen TDataCursor.RefreshCurrentRecord >> 00813772 +02a RemoteBuyer.exe dbisamen >> TDataCursor.RepositionCurrentRecord >> 007ff013 +027 RemoteBuyer.exe dbisamen TDataCursor.CheckForCursorChanges >> 007ff03a +01e RemoteBuyer.exe dbisamen >> TDataCursor.CheckForChangeDetection >> 0080bc8b +19f RemoteBuyer.exe dbisamen TDataCursor.Locate >> 00887fbe +3ee RemoteBuyer.exe dbisamtb TDBISAMDataSet.LocateRecord >> 008881d9 +025 RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate >> 009532dd +31d RemoteBuyer.exe MainForm 3379 +51 >> TClockTestForm.findFlowerImage >> >> The "findFlowerImage" attempts to "Locate" a record in the local >> PinnedWagons table based on item code, line #, etc. and then uses some >> fields from PinnedWagons to locate an exact picture for the product >> (e.g. red rose vs. fire-and-ice rose, etc.) in a separate images table. >> >> >> On 10-02-02 11:06 AM, Raul wrote: >>> >>> Error 9217 often is due to a corrupted table or some file level >>> interference like AV: >>> >>> - have you done a repair? >>> >>> - reboot the computer just to be safe and also turn off AV ? >>> >>> Is the error reproducible ? >>> >>> Raul >>> >>> >>> "Michael Gonyea" <mlgsolutions@gmail.com> wrote in message >>> news:ED076E32-9BB6-43A0-874F-84AA4B6F2EA0@news.elevatesoft.com... >>>> Hi folks, >>>> >>>> Having some trouble with DBISAM that I can't quite track down. Here's >>>> some background on our development environment: >>>> >>>> Delphi 2007 >>>> DBISAM Version 4.26 Build 3 >>>> madExcept >>>> >>>> We have two separate applications that access a local table. At any >>>> point during the application, exe #2 will add/remove/change records in >>>> the local table, which exe #1 uses in a read-only fashion (i.e. exe #1 >>>> only performs "locates" on the table, but never adds/changes/deletes >>>> records). Here is an excerpt from one of the madExcept reports, along >>>> with an explanation of what was happening with our 2 applications: >>>> >>>> exception class : EDBISAMEngineError >>>> exception message : DBISAM Engine Error # 9217 Error reading from the >>>> table or backup file 'PinnedWagons'. >>>> >>>> Main ($208): >>>> 0087e3fd RemoteBuyer.exe dbisamtb DBISAMError >>>> 007e6542 RemoteBuyer.exe dbisamen TDataEngine.RaiseError >>>> 00813a0a RemoteBuyer.exe dbisamen TDataCursor.CheckError >>>> 00885ea3 RemoteBuyer.exe dbisamtb TDBISAMDataSet.GetRecord >>>> 004f66f9 RemoteBuyer.exe DB TDataSet.Resync >>>> 008881fe RemoteBuyer.exe dbisamtb TDBISAMDataSet.Locate >>>> 00954f2e RemoteBuyer.exe MainForm TClockTestForm.GridProductsSelectCell >>>> 0067b92e RemoteBuyer.exe Grids TCustomDrawGrid.SelectCell >>>> 00678e1e RemoteBuyer.exe Grids TCustomGrid.MoveCurrent >>>> 00678daa RemoteBuyer.exe Grids TCustomGrid.MoveAnchor >>>> 00677e8a RemoteBuyer.exe Grids DoChange >>>> 00677fb2 RemoteBuyer.exe Grids TCustomGrid.ChangeSize >>>> 0067ac88 RemoteBuyer.exe Grids TCustomGrid.SetRowCount >>>> 00681308 RemoteBuyer.exe Aligrid TStringAlignGrid.RemoveRow >>>> 009689cd RemoteBuyer.exe pinnedList TPinned.delete >>>> 00967298 RemoteBuyer.exe dtmdlRB TdmRemoteBuyer.PinnedWagonsChanged >>>> 0093836a RemoteBuyer.exe TCPDataServer TDataServerRecvThread.RunCommand >>>> >>>> Explanation: >>>> >>>> EXE #2 (our "data service") deletes a records in the local >>>> "PinnedWagons" table and then sends a message via TCP to EXE #1 which >>>> triggers a "PinnedWagonsChanged" procedure to run in EXE #1. The >>>> "TPinned.delete" method removes an item from a custom TList object, >>>> then proceeds to visually remove row <x> from a non-data-aware grid. >>>> After the row is removed, we trigger a manual "re-select a grid line" >>>> which in turn performs a lookup on the local "PinnedWagons" table to >>>> obtain some record info to be displayed on the screen (size, colour, >>>> item code, etc.) At this point, the exception is triggered. >>>> >>>> Any ideas? I have more examples if that helps. >>>> >>>> Thank you in advance! >>>> >>>> __________ Information from ESET NOD32 Antivirus, version of virus >>>> signature database 4828 (20100202) __________ >>>> >>>> The message was checked by ESET NOD32 Antivirus. >>>> >>>> http://www.eset.com >>>> >>>> >>>> >>> >>> __________ Information from ESET NOD32 Antivirus, version of virus >>> signature database 4829 (20100202) __________ >>> >>> The message was checked by ESET NOD32 Antivirus. >>> >>> http://www.eset.com >>> >>> >>> >> >> __________ Information from ESET NOD32 Antivirus, version of virus >> signature database 4829 (20100202) __________ >> >> The message was checked by ESET NOD32 Antivirus. >> >> http://www.eset.com >> >> >> > > __________ Information from ESET NOD32 Antivirus, version of virus > signature database 4829 (20100202) __________ > > The message was checked by ESET NOD32 Antivirus. > > http://www.eset.com > > > |
Wed, Feb 3 2010 12:33 PM | Permanent Link |
Michael Gonyea | Hi Tim,
The 2 apps currently only have a TDBISAMDatabase component - I assume they're both using the default values. I will add a TDBISAMEngine component and ensure that the settings are identical for both apps. Thanks! On 10-02-03 7:28 AM, Tim Young [Elevate Software] wrote: > Michael, > > << We have two separate applications that access a local table. At any > point during the application, exe #2 will add/remove/change records in the > local table, which exe #1 uses in a read-only fashion (i.e. exe #1 only > performs "locates" on the table, but never adds/changes/deletes records).>> > > Are either of the applications compiled with the > TDBISAMEngine.LargeFileSupport property set to True ? If so, are they > *both* set to the same setting ? > |
Thu, Feb 4 2010 10:00 AM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | Michael,
<< The 2 apps currently only have a TDBISAMDatabase component - I assume they're both using the default values. I will add a TDBISAMEngine component and ensure that the settings are identical for both apps. >> If that's the case, then you're okay already, and there's no need to use the TDBISAMEngine component. I would try the latest version and see if it has been fixed, and if not, then we can take it from there. -- Tim Young Elevate Software www.elevatesoft.com |
This web page was last updated on Wednesday, April 17, 2024 at 10:35 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |