Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » DBISAM Technical Support » Support Forums » DBISAM General » View Thread |
Messages 1 to 10 of 10 total |
DBISAM v4.22 |
Wed, Feb 14 2007 7:13 AM | Permanent Link |
Nuno Fonseca | 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, |
Wed, Feb 14 2007 10:23 AM | Permanent Link |
"Jose Eduardo Helminsky" | 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 |
Wed, Feb 14 2007 12:07 PM | Permanent Link |
Sean McCall | 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, > |
Wed, Feb 14 2007 12:16 PM | Permanent Link |
"Frans van Daalen" | "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? |
Wed, Feb 14 2007 4:24 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Fri, Feb 16 2007 6:16 AM | Permanent Link |
Nuno Fonseca | 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, |
Fri, Feb 16 2007 6:59 AM | Permanent Link |
Nuno Fonseca | 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, |
Fri, Feb 16 2007 7:00 AM | Permanent Link |
"Jose Eduardo Helminsky" | Nuno
Even when you close and show the form again the data does not appear ? Eduardo |
Fri, Feb 16 2007 3:21 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | 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 |
Thu, Feb 22 2007 7:39 AM | Permanent Link |
Nuno Fonseca | "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, |
This web page was last updated on Wednesday, August 14, 2024 at 03:12 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |