Kick out procedure not working

[NauticalGent]

Howdy all,

Not too long ago I incorporated a "kick out" procedure that worked like a charm. It involved a hidden form with a timer event, a table with a "kick out" flag...all the normal bells and whistles you can find on numerous forums like this one.

Last week I migrated the BE tables to SharePoint and now the procedure's performance is spotty. It only kicks out some users and totally ignores others. Before I start looking "under the hood" in depth, has anyone experienced anything like this?

Thanks in advance!

 

[The_Doc_Man]

At least one such case of this turned out to be that the person being kicked out had left a form open and dirty, then walked away. Because I had safeguards for "dirty exits" I was in a quandary of sorts. I needed to not only close the form but to force an UNDO before I could allow it to close, and the "BeforeUpdate" event didn't include the UNDO, it just canceled the update. Which meant that I couldn't close the form and do the kickout because the form was still dirty.

The typical solution for this involves keelhauling the culprit as an example, but I was advised that it would not be a good idea in our environment.

 

[NauticalGent]

Interesting. This COULD be the issue but it would be highly coincidental since I did not have it this issue when the BE was on a shared drive.

The majority of the code use comes from Andrew Couch's Access VBA book...he included a process that identifies each open object (forms and reports) then saves and closes them.

This could be an explanation as to why I haven't had the "dirty" problem you are talking about. That being said, I am still going to do a field test to see if that causes the problem. I was also wondering if the delayed write/cache properties of linked SharePoint lists might be the culprit...?

Fun stuff...

 

[The_Doc_Man]

Less a matter of delayed write/cache, I would think, and more a matter of different sharing rules and timing. Might be time to check the SharePoint manuals for special rules for forcing transaction closure.

Let me put it this way: If a write or a cache update has been committed and the Application.Quit causes you to lose that data, SharePoint is written incorrectly - and while I don't claim Microsoft to be perfect, this is the kind of error that would make the product unusable. I'm not seeing THAT kind of chatter.

 

[NauticalGent]

Almost embarrassed to post the resolution, but hopefully others will learn from my stupidity. I neglected to say that I also introduced 2 new forms when I migrated...one of them was Modal. To make matters worse, the modal form had to be opened to do the majority of the application.

Just happened to be looking over somebody's shoulder when he closed the form and "presto" the boot-out warning flashed on his screen.

See what happens when you assume someone knows what they are doing??