Will a client force-quit stop a loop?

[dubl]

Hi,

Last week a client of my taxi solution phoned to say that she had made a boo-boo in entering some dates, and the machine was in a 'creating records' loop.

Basically the story is this:

When a driver is not going to be available to drive for a depot for a period of time, a record is created in the Holidays table for each shift and date that s/he will not be driving.

So the user enters a start date and end date and the script starts a loop which creates two records for each date between the start and end date.

She mistakenly swapped the start and end dates around and clicked the Start button. (I had unfortunately not yet updated her to the latest build, which checks for just this occurrence)

Anyway, she was watching the record count increasing. I told her to force quit, since I had Allow User Abort turned off.

When she logged in and went back to the same layout, she said that the record count was STILL increasing. I didn't quite believe her myself (having seen clients do strange things) so I logged in using Remote Desktop Client to the server and indeed I saw the same thing - this was from a different client to her machine.

The only way I could get it to stop was to use FMS Admin to close all databases and when I started them again and logged in, the loop had stopped.

I was certainly under the impression that a loop started on a client would stop when that client disconnected or did a force quit.

But it seems I was wrong?

Any takes on this?

Steve aka Dubl

[Ocean West]

Hi Steve,

No I had not seen this behavior, as a scripted process is local to the client if you forced quit the chance that the users session was still opened at the server, did you log in to the server and confirm the end user was disconnected, before relaunching the client?

It is possible that the script actually quit but when you log back in and navigate to the layout the dates are not in the correct sequence and another script could be doing some forgotten error trapping looping function not expecting the incorrect data or some flag that didn't get triggered cause the first script never finished? - just guessing.

[dubl]

Thanks Stephen

No - one thing I did not check via FMS Admin was if the client was still connected after the force quit.

That must have been it, since there are no other looping processes that could have been happening.

Cheers

Steve

[Ocean West]

Are they using box copies or VLA?

[dubl]

They are on VLA - would this make a difference to a box copy?

[Ocean West]

Well a box copy would have told them that they reached the maximum number of licenses preventing them from signing right back on. (usually need to restart machine or wait for server to time out session) But with VLA that message isn't seen, so my guess server didn't disconnect the user and they logged back in - it reconnected the same session? not sure if it's possible. - but you said they logged in w/ different client and seen the numbers increasing - very odd.

It would probably be faster to trap for accurate date range data then to figure out what caused this issue - however inquiring minds would like to find if it is repeatable and truly a FMP/FMS bug... Should mention it to OAM...