Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General Discussion » View Thread |
Messages 1 to 4 of 4 total |
Using DevExpress Editors and ElevateDB in a multi-user environment |
Tue, Jan 29 2013 1:30 PM | Permanent Link |
Ian Turner | 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 |
Wed, Jan 30 2013 4:42 AM | Permanent Link |
Matthew Jones | 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/ |
Wed, Jan 30 2013 11:01 AM | Permanent Link |
Ian Turner | (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 |
Thu, Jan 31 2013 10:46 AM | Permanent Link |
Ian Turner | (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 |
This web page was last updated on Wednesday, June 12, 2024 at 01:54 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |