Tim

>Do you have a filter on the detail table in addition to the master-detail
>linkage ? Just closing a detail table shouldn't cause that much activity
>across the network, and DBISAM will most definitely not read the entire
>detail table just because the master-detail linkage is gone.

Unless it was being displayed in an unbound grid.

Roy Lambert [Team Elevate]

It is attached to a DevExpress DBPivotGrid, so perhaps that was part of the issue.

It was just throwing me with all of the variable situations...

Anyway, the problem is now fixed.  I'm guessing another possibility in retrospect would have been to set the DBPivotGrid's datasource to nil before closing as well.

I can reverse the lines and try this if you'd like me to.  That way we could determine what the actual issue was.

Went ahead and tried that, but it didn't make a difference.

FYI, I changed my CloseDB routine to:

procedure TFrmMain.CloseDB;
begin
 cxGridHeaderDBTableView.DataController.DataSource:=nil;
 cxDBPvGridScheduler.DataSource:=nil;
 ActnCollapse.Execute;
 UpdateStatBar('Closing Database...');
 DBISAMTblOASMachNoOrders.Close;
 DBISAMTblOASHistoryHeader.Close;
 DBISAMTblOASHistory.Close;
 DBISAMDBOASScheduler.Close;
 DBISAMEngineMain.Active:=False;
 UpdateStatBar('');
end;

You can see I reversed the close routines so that DBISAMTblOASHistoryHeader closes before DBISAMTblOASHistory and set the PivotGrid's DataSource to nil.

Here is the actual CloseDB routine that works fine:

procedure TFrmMain.CloseDB;
begin
 cxGridHeaderDBTableView.DataController.DataSource:=nil;
 ActnCollapse.Execute;
 UpdateStatBar('Closing Database...');
 DBISAMTblOASMachNoOrders.Close;
 DBISAMTblOASHistory.Close;
 DBISAMTblOASHistoryHeader.Close;
 DBISAMDBOASScheduler.Close;
 DBISAMEngineMain.Active:=False;
 UpdateStatBar('');
end;

So closing the OASHistory table BEFORE I close OASHistoryHeader is what fixes the issue.

Robert


I'm guessing the underlying issue is still in hiding somewhere.

Throughout my apps I have AppClosing and FormClosing booleans (AppClosing being app wide and FormClosing local to the form) because of issues with how DB attached controls can work. In my case it was mainly AVs or "Table not open" type problems often caused by an OnChange event in a TDBEdit. You close the table that means that the field in the TDBEdit has changed (unless it was null before) and that then spews out notifications and other events fire.

Simple forms seem immune but as the complexity level rises - watch out.

Roy Lambert

True...  I've run into several of these myself.  My main form IS pretty complicated as I'm using a lot of DevExpress controls in it (a cxGrid, cxDBPivotGrid, dxBarManager, etc.).  If there is a buried issue somewhere, I would hate to try to find it through all of that 3rd party source!

Roy Lambert wrote:

Robert


I'm guessing the underlying issue is still in hiding somewhere.

Throughout my apps I have AppClosing and FormClosing booleans (AppClosing being app wide and FormClosing local to the form) because of issues with how DB attached controls can work. In my case it was mainly AVs or "Table not open" type problems often caused by an OnChange event in a TDBEdit. You close the table that means that the field in the TDBEdit has changed (unless it was null before) and that then spews out notifications and other events fire.

Simple forms seem immune but as the complexity level rises - watch out.

Roy Lambert

Robert,

<< It is attached to a DevExpress DBPivotGrid, so perhaps that was part of
the issue. >>

Yes, that is definitely the issue.  You can verify this by doing what you
suggest - setting the control's DataSource to nil before closing.  DBISAM
will simply never read more than the number of visible lines in a TDBGrid
control, *unless* you have a 3rd party data-aware control attached that
reads a lot more than that whenever the underlying dataset changes.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim,  if you look a couple posts above, I did try that, but it didn't make any difference...

Robert,

<< Tim,  if you look a couple posts above, I did try that, but it didn't
make any difference... >>

I guarantee that the problem is somewhere in one of the data-aware controls
that you're using.  If you want to send me your source code, I can tell you
where.  It would probably help you a lot to know which component to be
careful about when it comes to how it is loading records.

--
Tim Young
Elevate Software
www.elevatesoft.com

As for the source code, do you need everything?  I use several 3rd party components, you might not have access to all of them.

Robert

>As for the source code, do you need everything? I use several 3rd party components, you might not have access to all of them.

That usually makes things difficult What I've usually done in these circumstances is start deleting components from the form and running it. Its a grotty, and boring job, but you will find the underlying problem.

Roy Lambert [Team Elevate]