A couple of years back I found what I considered to be a major flow in the way DevExpress Editors handle an underlying dataset refresh. Fundamently, if you display a form with a TcxDBTextEdit editor and place the cursor in that editor, then run a second copy of the program and edit that field and post the change, then try to edit the field in the first copy of the program the editor's text is not refreshed with the new data. This is the case if RecordLockProtocol is set to Optimistic or Pessimistic and the data set refresh done manually. The same example works perfectly with the standard Delphi TDBEdit component

DevExpress first agreed it was reproducable, muttered somehting about looking for a solution, waited a month and then decided it was a "feature". To my mind that makes it unusable for serious multi-user access ... unless of course I am missing something fundamental.

I am now looking at starting a major multi-user project and so my question is what does everybody here use for the their form editors?

Any suggestions greatfully received.
Thanks,
Ian

I think the real question is what you actually expect to happen. How do you expect
they will know that something changed, and what if two users are typing at the same
time? I'd start by looking at how the underlying dataset knows that a change
happened, and what is happening to the record. Does the change show up in a label
showing the field too? I would presume that the dataset will get an event to
indicate an update if it is able to detect it.

From my understanding of the DevExpress components, which is vague in details, they
essentially will be starting a fresh editor when you start editing. Thus the
underlying data is not touched until you finish editing (the immediate post option
is relevant IIRC). To link the two would probably be hard, so I can see why they
label it a "feature". But that doesn't stop you using the "updated" event from the
dataset to alert the user and offer a refresh of the form. In some ways you might
argue this is better. Alternatively, stop linking the fields to the database
directly, and do the posting yourself direct to the fields. Then you can gain more
control.

/Matthew Jones/

(Matthew Jones) wrote:

<<I think the real question is what you actually expect to happen. How do you expect
they will know that something changed, and what if two users are typing at the same
time? I'd start by looking at how the underlying dataset knows that a change
happened, and what is happening to the record. Does the change show up in a label
showing the field too? I would presume that the dataset will get an event to
indicate an update if it is able to detect it.

From my understanding of the DevExpress components, which is vague in details, they
essentially will be starting a fresh editor when you start editing. Thus the
underlying data is not touched until you finish editing (the immediate post option
is relevant IIRC). To link the two would probably be hard, so I can see why they
label it a "feature". But that doesn't stop you using the "updated" event from the
dataset to alert the user and offer a refresh of the form. In some ways you might
argue this is better. Alternatively, stop linking the fields to the database
directly, and do the posting yourself direct to the fields. Then you can gain more
control.
>>
Thank you for your reply Matthew. Apologies for being so poor at explaining this.  If you use the standard Delphi TDBEdit components on a form to display and edit fields on an ElevateDB table then run two instances of that program. If the two instances display the same record and one instance edits a field, then posts it, when the other instance tries to edit the same record ElevateDB recognises that the buffer is dirty and forces a refresh. This refreshes all the TDBEdit components on the form, including the one that you tried to edit if that was the one that was changed. Now ok it looks a bit scrappy when the field is refreshed and you end up at the beginning of the edit box, but its not a disaster.

BUT with the DevExpress TcxDBTextEdit component the field that you type into does not get refreshed, so you can carry on typing and the dirty buffer, along with the edit will overwrite the previous edit!... and for some daft reason DevExpress thinks this is a feature. To be honest I don't think they know how to fix it so have deployed the Ostrich method of support.

Apologies for the rant. All this is not the fault of Elevatedb. Just wondered what other people used for their DBEdit components in a mulitiple user environment.

Thanks, Ian

(Matthew Jones) wrote:

<<But that doesn't stop you using the "updated" event from the
dataset to alert the user and offer a refresh of the form. In some ways you might
argue this is better.>>

I think that it was I am doing at the moment -

procedure TForm1.taTestEditError(DataSet: TDataSet; E: EDatabaseError;
 var Action: TDataAction);
begin
  Action:=daAbort;
  if (E is EEDBError) then
  begin
    if (EEDBError(E).ErrorCode = EDB_ERROR_LOCKROW) then
    begin
      if MessageDlg('The record you are trying to edit ' +
          'is currently locked, do you want to ' +
          'try to edit this record again?', mtWarning, [mbYes, mbNo], 0)
        = mrYes then
        Action := daRetry;
    end
    else if (EEDBError(E).ErrorCode = EDB_ERROR_ROWMODIFIED) then
    begin
      MessageDlg('The record you are trying to edit ' +
          'has been modified since it was last ' +
          'retrieved, your copy will now be ' + 'refreshed', mtWarning, [mbOk],0);
          dataset.Cancel;
          dataset.Refresh;
    end
    else
      MessageDlg(E.Message, mtError, [mbOk], 0);
  end
  else
    MessageDlg(E.Message, mtError, [mbOk], 0);
end;

===========
This works fine for the standard TDBEdit, but the dataset cancel and refresh is ignored by the DevExpress TcxDBTextEdit component that is being edited.

regards,
Ian