We have a strange situation.
If we update a record in a table in one LAN terminal, sometimes another terminal doesn't
reflect the update even after 90 minutes.
In the AfterPost event of every table we call FlushBuffers and when showing the grids with
the data we call the Table's Refresh method.

This is causing us some headaches and we need help a.s.a.p. We don't want to use
StrictChangeDetection because we tried it in DBISAM V3 and it delayed the application a lot.

Regards,

Nuno

> If we update a record in a table in one LAN terminal, sometimes another
> terminal doesn't
> reflect the update even after 90 minutes.
> In the AfterPost event of every table we call FlushBuffers and when
> showing the grids with
> the data we call the Table's Refresh method.

Are there any timers or any method on each LAN terminal to refresh the data
?

Eduardo

Nuno,

Is the change being shown if you close the application and re-open it or
if you use DBSys?

If so, are you sure the refresh is being called when you think it is
with the grids? If the form that contains the grid is not dynamically
created or depending on how you coded the form, the Refresh may not
executing when you close and reshow the form. Try putting a button on
the form that will refresh the table and see if that makes a difference.
You could also update the form's caption when you call the refresh to
show the time of the last refresh until you can solve the problem.

HTH,

Sean

Nuno Fonseca wrote:
> We have a strange situation.
> If we update a record in a table in one LAN terminal, sometimes another terminal doesn't
> reflect the update even after 90 minutes.
> In the AfterPost event of every table we call FlushBuffers and when showing the grids with
> the data we call the Table's Refresh method.
>
> This is causing us some headaches and we need help a.s.a.p. We don't want to use
> StrictChangeDetection because we tried it in DBISAM V3 and it delayed the application a lot.
>
> Regards,
>

"Nuno Fonseca" <delphi@filosoft.com.pt> wrote in message
news:733A71E4-4978-4F65-9B40-0FB5144B0DBA@news.elevatesoft.com...
> We have a strange situation.
> If we update a record in a table in one LAN terminal, sometimes another
> terminal doesn't
> reflect the update even after 90 minutes.
> In the AfterPost event of every table we call FlushBuffers and when
> showing the grids with
> the data we call the Table's Refresh method.
>
> This is causing us some headaches and we need help a.s.a.p. We don't want
> to use
> StrictChangeDetection because we tried it in DBISAM V3 and it delayed the
> application a lot.
>
Update via tTable or tQuery. If tQuery: Are you sure that the result is
live?

Nuno,

<< We have a strange situation. If we update a record in a table in one LAN
terminal, sometimes another terminal doesn't reflect the update even after
90 minutes. In the AfterPost event of every table we call FlushBuffers and
when showing the grids with the data we call the Table's Refresh  method. >>

What the others have suggested is what I would suggest, especially checking
to see if the result set is live if you're using a TDBISAMQuery.

Also, are you sure that you're looking at the same exact table on both
workstations ?

--
Tim Young
Elevate Software
www.elevatesoft.com

We are not using Queries.
The refresh method is called on the create event of each form. The forms creation is dynamic.
If we close and re-start the application the data is refreshed.


Regards,

Tim,

We are sure the table we are browsing in both terminals is the same.

We have been testing the StrictChangeDetection property.
It works fine, but is too slow for this huge application. As far as we could understand,
the StrictChangeDetection property, when active, checks for table and record changes... Is
there any way that we can automate only table changes detection (added record, deleted
record, etc) without using StrictChangeDetection ?
Using refresh everywhere it may be needed would be very time consuming for us, because
this application is really huge. But if we have to do it, we will.

Regards,

Nuno

Even when you close and show the form again the data does not appear ?

Eduardo

Nuno,

<< We are sure the table we are browsing in both terminals is the same. >>

Frankly, the situation that you describe is impossible then.  There's no way
that DBISAM will not see changes on the same table in a Refresh.

<< We have been testing the StrictChangeDetection property. It works fine,
but is too slow for this huge application. As far as we could understand,
the StrictChangeDetection property, when active, checks for table and record
changes... >>

The difference is that StrictChangeDetection checks for changes before any
operation:

http://www.elevatesoft.com/dbisam4d5_change_detection.htm

<< Is there any way that we can automate only table changes detection (added
record, deleted record, etc) without using StrictChangeDetection ? >>

DBISAM always checks for changes before any insertion, modification, or
deletion of records.  And the way to check for changes outside of these
operations is to use Refresh.

--
Tim Young
Elevate Software
www.elevatesoft.com

"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> wrote:

Nuno,

<< We are sure the table we are browsing in both terminals is the same. >>

Frankly, the situation that you describe is impossible then.  There's no way
that DBISAM will not see changes on the same table in a Refresh.

<< We have been testing the StrictChangeDetection property. It works fine,
but is too slow for this huge application. As far as we could understand,
the StrictChangeDetection property, when active, checks for table and record
changes... >>

The difference is that StrictChangeDetection checks for changes before any
operation:

http://www.elevatesoft.com/dbisam4d5_change_detection.htm

<< Is there any way that we can automate only table changes detection (added
record, deleted record, etc) without using StrictChangeDetection ? >>

DBISAM always checks for changes before any insertion, modification, or
deletion of records.  And the way to check for changes outside of these
operations is to use Refresh.

--
Tim Young
Elevate Software
www.elevatesoft.com


Hi Tim,

Yes I know this seems impossible. I will have to check my colleague's code to see if there
is something wrong there.

Regards,