0

at the moment we are migrating the database component of our Delphi7 application from the BDE components to the AnyDAC Version 8.0.5 components.

The TTable (BDE) has the following behavior, before editing the record from another application instance (session):

  1. The record is refreshed and changes are visible from other instances. The record will be refreshed in the method TBDEDataSet.InternalEdit.
  2. The dataset is set into edit mode (DataSet.State = dsEdit)

Using the appropriate AnyDAC components (TADTable) the records does not reflect the changes done by other instances. No special changes to TADConnection and TADTable are made.

Any help appreciated.

Mr.Darcy
  • 11
  • 2

1 Answers1

0

I cannot speak for BDE as I don't want to get in touch with it anymore, but what you've described I can read like:

Why does not AnyDAC refresh the tuple before editing starts?

If that is so, and correct me if I'm wrong, that would be quite against UX. Imagine, that you were a user of your own application and wanted to edit a certain tuple in a data grid view. You would click some edit button to enter editing mode, and the whole row would suddenly change in front of your eyes (or editor would be filled by different data than you've seen). Would you like this to happen?

If so, then I'm afraid you'll need to perform such refresh manually with AnyDAC (or FireDAC). The point here is that the engine either locks the tuple by transaction, or tracks the changes inside the internal storage whilst you're in the editing mode.

In neither case refreshes the tuple before editing starts (no matter which locking options you use). And I'm personally fine with this behavior as it could lead to what I've described above.

So how can I refresh the active tuple before editing starts then?

To refresh particular tuple to which the dataset cursor points before dataset editing starts you can call e.g. RefreshRecord from the BeforeEdit event, for example:

procedure TForm1.ADTable1BeforeEdit(DataSet: TDataSet);
begin
  TADTable(DataSet).RefreshRecord;
end;

But then your database editing capability becomes a moving target (well, maybe it is already).

Victoria
  • 7,822
  • 2
  • 21
  • 44
  • Thank you for your detailed explanation... Unfortunately, our users have already become accustomed to the behaviour of the BDE. So we have to overthink how we can solve this "issue"... – Mr.Darcy Mar 02 '18 at 08:55
  • I've stepped through the _whole_ process of editing and there is no refetch implemented. So your options are narrowed to method like `RefreshRecord`. Well, and I'd say the proposed `BeforeEdit` event is the right place for it. Well, maybe, but it would be horrible, you could try to break the tuple in the storage and let the engine fetch it from the source again. But it's so ugly that I haven't researched on this. – Victoria Mar 02 '18 at 09:11