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!

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

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
>
>
>

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

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

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
>
>
>

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 ?
>

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