Multiple users/clients editing/viewing single databse

I bring the source data into each editable field in a Raw custom property. When no edits have started, propertyChange events on Raw are just copied over to the real entry field. Another custom property, a boolean Dirty, has an expression comparing the two properties. ‘Dirty’ drives the color coding.

When editing directly in a table, I bring the source data to a Raw dataset property and color-code from that.

Are your editing areas separate screens/windows? So, they can’t select a different row after they start making changes?

I sometimes have the editable fields on the same window as the table they select which row to edit. The issue here is they can select a different row unless you prevent that, which I started doing recently. I’m trying to prevent less mouse clicks. I’m not a huge fan of editing within the table, especially since there are issues with dropdowns (reported this to IA last week.)

I was thinking about using messages for multiple users. Thanks for the tips.

I usually do a side-by-side. Starting edits disables the table/list of rows until save/cancel.

Great, that’s exactly what I ended up dong as well.

It’s requested by the end user they don’t want multiple people to even be on the same window at the same time. They would entertain the idea that the window be read only. So, curious how to manage this best. Use client/gateway tags to keep track?

I’ve never done that. Certainly need something in the gateway to moderate access. Will be a nightmare to manage broken connections or sudden client shutdown. I strongly recommend against a window lockout approach.

What would be your approach, to manage as they accept edits? Still, how do you know who was there first? I don’t want last wins, I want first wins.

How do you define first? By that I mean, how long or what criteria to you use to decide another edit is allowed? One minute? One hour? Something changing in the process?

Last wins is unambiguous, and if a user has permission to edit, why shouldn’t they be allowed? Whether they were first or last into that window?

As for managing the data, I think notification of others’ changes while in the window is sufficient. Don’t make arbitrary barriers to getting a job done.

Exactly my point for asking the question…If I knew, I wouldn’t be posting. :slight_smile:

Customer request, which I always try to accommodate.

Yes, but the customer can be asked to define exactly what they want. When they are asking for something difficult (or impossible), the effort to define it can expose the money pit they are about to fall in.

Ok, we can leave it there then, not really interested in silly debates.

I wouldn’t call it a debate. It’s just that what your customer wants is rather difficult.

I’m just getting back around to this. I would like to simplify things and give a notice when multiple users are editing the same thing. I have things kind of working but have an issue.

I have a tree view where they select what they want to edit. I get an Id from this. On this Id’s property change event, I send out a client message. I send out the Id of the tree view, the client id and project name. In the client message I determine if they are on the same window, if not I move on. If they are, I again grab the tree view Id and compare the client Ids.

What this gets me is a notification on the client that didn’t just make a new selection, the other client(s) will get the message. My goal is for all clients on the same Id to get the message. I have played around with a few things and just not making headway. Any advice on this?

Sounds like you need some kind of cache of what client Ids have navigated to what tree Ids.

I was able to get what I need by cascading messages. I tested with 3 clients and it will display a message box for each client that is trying to edit the same thing. Only issue, if a user doesn’t acknowledge the message box and another client repeatedly selects the same ID it will blast message boxes for each occurrence. Any elegant way to know if a message box is opened and if it is don’t allow another one?

Disregard, I have things working. Thanks for the direction Phil.

Message boxes block all foreground script execution and property change propagation. Don’t ever trigger them except by that client’s user action. (Or never at all.) Use a popup window if you need such.

I considered creating a popup, but after some testing the message boxes are more desirable. The users aren’t supposed to be hanging out on these windows, so if they get annoyed with a ton of message boxes, well lesson learned. :slight_smile: Also, the chances of multiple users selecting and/or editing the same thing is quite rare. Probably better chance to win the lottery.