Interesting Frontend Behavior

[MNottingham]

So, here is the situation as it stands.
The database in question is for equipment inspections. It has one back end and multiple frontends that are in use at the same time. Each user selects a piece of equipment that they have performed an inspection or maintenance on to record it, this happens all around the same time with as many as 4 users making changes at once.

Now here's where things get strange. The equipment number is selected using a drop down, and when one user selects a piece of equipment it will change the selected equipment on the other frontends currently engaged with the backend.

I have attempted to uncouple the dropdown from the field it was attached to in the primary table (the equipment ID table) and only use the equipment ID table (the basis for all records in the system) to populate the drop down, which for some reason drives the entire front end in to death spiral and causes co-mingling of records on the form in question.

So, the question is... how do I keep the system as is and stop the system from changing the record for all front ends when only one is changed? I would also like to know if anyone knows why this happens, I think I know why but if anyone has the exact answer that would help me greatly.

 

[missinglinq]

Most curious, and smells strongly of corruption!

First off, I assume that the shared Back End holds all Tables, while the copy of the Front End, on each user's PC, holds everything else; is this correct?

Next, I guess we need to see the actual code that is being used by the Combobox to retrieve the desired Record.

Finally, in Form Design View, if you

1. Right-Click on the Combobox
2. Click on Properties
3. Click on the Data Tab
4. Look at the Control Source Property

do you see anything in the Property Box, such as a Field Name?

Linq ;0)>

 

[MNottingham]

Yes there is in fact a record selected by the drop down, and this in my opinion is the source of the behavior as if User 1 uses the drop down to select a piece of equipment he's setting the selected record for everyone using that particular form (on any of the open frontends). So, what I did was uncouple the record from the drop down (so now it doesn't select a record but rather the form responds to the text selected in the box, not the record selected) and after some experimentation I have found the problem reported by the users, there are a few fields in the form that relied on the drop down to find their values, so now I need to figure out how to get them moving along when the drop down is changed.

I figure the best way to do this is to write a query for these few fields and use criteria in said query to match them to the selected equipment in the drop down.

Thanks for the response, and any suggestions are welcome.

 

[Solo712]

Yes there is in fact a record selected by the drop down, and this in my opinion is the source of the behavior as if User 1 uses the drop down to select a piece of equipment he's setting the selected record for everyone using that particular form (on any of the open frontends). So, what I did was uncouple the record from the drop down (so now it doesn't select a record but rather the form responds to the text selected in the box, not the record selected) and after some experimentation I have found the problem reported by the users, there are a few fields in the form that relied on the drop down to find their values, so now I need to figure out how to get them moving along when the drop down is changed.

I figure the best way to do this is to write a query for these few fields and use criteria in said query to match them to the selected equipment in the drop down.

Thanks for the response, and any suggestions are welcome.

Hi there,
this should not be happening at all. If the form sits in the FE, presumably on the users' computers, there should be four independent connections to the table in question, and the users should be able to interact with the data without interfering with each other. Rather than trying to protect the users from this bizzare behaviour you should try to find out what causes the anomaly. It will be time well spent.

By what you describe, it almost sounds like the form sits in the back-end. I have seen it before where a programmer had a form in the back-end after splitting the database (Don't remember how that happened, most likely forgot to transfer it manually). Caused all sorts of funny things though I can't honestly say that it was what you describe. Check it out anyhow ! If it's not that, it is something else that isn't the way it should be. It's always best to deal with the root problem rather than rely on makeshift solutions. Split the database again ! See if the nonsense persists.

Just my $0.02

Best,
Jiri

 

[MNottingham]

Form is in the frontend, however the above suggestion about using the "Find" option for a combo is what I ended up doing last night, so props for that answer because its the best one for this sort of problem.

The reason this is happening seems quite simple after mulling through it. The combo was forcing a record selection in the main table so when user 2 would do anything in the form it would see that record selected by user one and move the front end for user 2 over to that record.

When you use the find option it uses the table BUT does not attach a source to the combo which eliminates the record switching between the front end.

Thanks for the help guys.

 

[MNottingham]

Ah, I understand now. With that once the box was unbound and corresponding Master/Child fields reset everything works great.