Job distributor

Thepieman

Registered User.
Local time
Today, 07:16
Joined
Dec 16, 2004
Messages
11
I am currently in the process of building a database to record IT faults which will then be picked up by engineers. The database has been built so that the engineers need to login using a user name and password (design lifted from this forum -THANKS http://www.access-programmers.co.uk/forums/showthread.php?t=64532)
Is there anyway that the database can automatically distribute jobs to anyone who is logged on at a rate of say one job every hour ? (preferably without using VB because I have no training.)
 
Well, yes and no. Lets say you have the users logon ID, and a tbl that has something with IDs and a tbl that shows he/she finished the task. Using a query or two one can find out if the last or any task has been completed by the logged on user and then have the computers clock to determine if there is someone needing a new job.

The question would be: what if many people have no jobs, which would it decide to assign the job.
 
Is there anyway that the database can automatically distribute jobs to anyone who is logged on

You have two possible cases:

1. Everyone has the same skills and/or the jobs are always alike.

2. Some people have skill-set A, others skill-set B, etc. etc. and the nature of the job is such that not everyone can do the same thing.

You must decide which of these applies and must design your DB to support the required decisions. We cannot help you until you decide which of these applies. If #2 applies, you have to worry about which parties are qualified to take the next job.

OK, some relevant issues:

How can you tell if someone is logged in? If you have a startup form, you have a possible way of knowing not only who is in, but also their login order. Some VBA code behind a startup form's OnLoad event could take their username and a time stamp to make an entry in a table. Make that form stay alive but minimized and/or not visible. The same form's OnExit event could be used to make logout entries.

Why do you want this? Because to select who gets the next job, you need a discriminator - and time of login could be part of that deal. Also, you said you needed to give this to any/every one who is logged in. Well, that means you have to KNOW who is logged in.

But if it were me, I wouldn't do it this way. I would make a form that gives out jobs when you click a button. If you don't click the button, you don't get another job. (If you aren't logged in, you can't click the button, so this indirectly meets your original criterion.) This allows fast workers to work fast and slow workers to work slow. Then it is up to you as to what you track for performance. But having a button-click event to drive the operation is probably the best way to do it.

You could build a job distribution form that has a timer in it. Say, once every minute or two or five (your choice), have it query the queue of pending jobs. If it is empty, display something. If not, display something else in a different color. You can also do such things as display the depth of the backlog.

Then, you advise your people that when they are ready to take on a new job, they run the job assignment form. If it shows nothing pending, well and good. If it shows that chaos has descended upon you, they can take the next job in sequence and hop to it. Just make it a single button that says "Take Next Job" and put all the smarts in the OnClick routine.

The problems I see with assigning jobs to folks who are logged in and basing it on the clock is that

1. The job might take longer than anticipated based on the rabbit stew theory of IT fault management. (To make rabbit stew, first you must catch the rabbit... after that, the time is predictable. But some rabbits are more elusive than others. Ask Elmer Fudd if you doubt me.)

2. You would not believe just how hard it is to tell that a particular user is logged on at the moment. You also would not believe how nasty a problem you give yourself by making it time-based. Besides which, see #4, because what you really DON'T want to happen is to cross-assign a job.

3. What do you do if someone walks away from a logged-in terminal and accumulates 20 jobs overnight because they were logged in? And along the lines of #2, if you can CROSS-ASSIGN a job (i.e. terminal A can give a job to terminal B), then terminal A absolutely needs to know unequivocally that someone is actually at terminal B to take the job. And I don't think you can guarantee that. Access, being network-distributed, is heir to the ills of that particular flesh - including crashes, network drops, and other ways of being marked as logged on when in fact it is totally dark at a particular terminal.

4. Assigning a job arbitrarily to a single person who is logged in from among a larger set of logged-in users actually is NOT possible because Access does not have a "central dispatcher" facility. You see, you don't have an Access application running. You have SEVERAL COPIES of that application, many of them running at the same time and all banging away at the same data set, each truly with a mind of its own. They could, in theory, ALL take the same job at the same time and then go hog-humpin' nuts trying to sort out file locks. By taking it "off the clock" you make it less likely (but NOT impossible) to have locking issues. If you used an external SQL server, this concern does not apply. But if you use a centrally located Access .MDB file that is shared to your users, it does apply.

This is technically a form of job dispatching or help desk dispatching, even if your users don't talk directly to your customers. You might wish to do a few web searches (and also search this forum) for help desk or support desk topics.
 
Thanks and more help please

Thanks - you're suggestion of allocating a job on the click of a button is a much better way of doing things !

Some info - yes everyone has the same skills and yes I do have a login form using a staff number and password (also records times each person was in the database).

The next plea for help is how do I get my db to allocate the faults on the click of a button ? (No VB please !)
 

Users who are viewing this thread

Back
Top Bottom