Updating Records Through Subform Row Selection

[pbaldy]

The absurdity was in your suggestion that Yes/No fields need to be removed from the table when a user leaves the company. That's almost a troll-like absurdity. You can ROTATE Yes/No fields: when one user leaves, another user takes his Yes/No fields, problem solved! That was what I meant: you had to make up this absurd scenario to prove a point.

If you scroll back you'll see I didn't suggest the deleting of fields, I asked if that's what you did. Like Vlad I would never use your method. It is only practical if you're an in-house developer and have relatively low turnover. In my opinion the developer should not have to modify the application when normal day-to-day activity like this occurs.



Again, I'm pointing out the cons so people can make an informed decision.

[keviny04]

@keviny04 - you seem to like your way and dismiss all the rest; I am not here to debate which method is the best.

I wouldn't use yours for a million bucks (if we get to use millions so easily ) as it would mean I would have to constantly adjust my interface to add fields to queries, forms, VBA, etc. And the tables won't be "all over the place", just one per front-end that can be re-used for multiple back-end tables.

Cheers,

You can avoid "constantly adjust" by having dynamically-constructed field names based on the user name. There is ALWAYS a way. And the user can't make local temp tables if it's a web form front end -- in which case you want to put the necessary fields at the *server*.

Of course, the even better way is to give your users a good filtering UI so he doesn't have to do silly checkboxing, check, check, check, etc.

[keviny04]

If you scroll back you'll see I didn't suggest the deleting of fields, I asked if that's what you did. Like Vlad I would never use your method. It is only practical if you're an in-house developer and have relatively low turnover. In my opinion the developer should not have to modify the application when normal day-to-day activity like this occurs.

Again, I'm pointing out the cons so people can make an informed decision.

"Suggest" doesn't always mean "suggest." For instance, "The moonlight suggests a peaceful mood." It means to evoke, to bring to mind. That was what I meant when I said about your "suggestion." You invoked such a silly idea as that. Anyway, it doesn't matter if you suggested or asked. You SAID it. If you insist on "asked", note that one can ask silly questions too.

[pbaldy]

You focus on triviality and ignore the main point, which is having to modify the database any time a mundane day-to-day act like hiring an employee happens. I would love to get a vote from developers here on whether they would ever do it. Vlad has already weighed in against.

[CJ_London]

I'm with everyone else - no way would I use Kevin's suggestion. But I wouldn't use a separate table either.

This is what I use when using checkboxes to select assorted records. It uses unbound checkboxes plus a textbox I call GF (for GotFocus) as a recipient of the focus to avoid the error the OP gets about a field not being editable.multiSelectFormWithChkBox.zip