By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,515 Members | 1,110 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,515 IT Pros & Developers. It's quick & easy.

REPOST: preventing more than one user from working on the same record

P: n/a
Hi,
I am working on an app that will display the list of all scheduled call
records in our database to the users. All users of the application will see
the same list of call records and will select any record and try to call the
contact person for that record and edit the record. Now, my question is how
do I prevent more than one user from selecting the same call record and
calling the same person?

Thanks in advance.
Mar 29 '06 #1
Share this Question
Share on Google+
3 Replies


P: n/a
I think the way I would probably approach this is as follows:

Each user has the list of calls. To begin a call, the user must double click
on the line in the list that corresponds to the person they want to call.

You immediately retrieve the record and check whether there is an operator
name attached to it. If not, you write this operators name to the database
(remembering to put a Where OpeatorName = '' in the SQL), checking to ensure
that the update works. IF the update fails, then someone else got in first,
so you tell the operator to pick another record.

If you were able to enter the operators name, then you pop up a window with
the call details, ready for the user to edit it. When they're finished, the
save or cancel and the window closes. At that stage, you save the data (if
requested). Presumably you also update a last contacted date to ensure that
the person isn't called again.

Only problem it gives you is where the operator does not close their system
properly and leaves with a record open. For this, I would probably also save
an "allocated to operator" date and time. Assuming no call takes more than
30 minutes, you could check, when you retrieve a record to see if the record
is over 30 minutes old. If it is, then reset the operator name and date and
assume the record isn't being attended to.

Hope that makes some sense.

Steve

"helpful sql" <no****@stopspam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Hi,
I am working on an app that will display the list of all scheduled call
records in our database to the users. All users of the application will
see
the same list of call records and will select any record and try to call
the
contact person for that record and edit the record. Now, my question is
how
do I prevent more than one user from selecting the same call record and
calling the same person?

Thanks in advance.

Mar 29 '06 #2

P: n/a
Mark the record as 'IsCalled' or so when a user selects on.
After edit and Lost_Focus set the Mark back.
Also edit a dattime with it, in case something goes wrong.
All the IsCalled records older than 1 or 2 days need to be reset.

Something like that, maybe?

"helpful sql" <no****@stopspam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Hi,
I am working on an app that will display the list of all scheduled call
records in our database to the users. All users of the application will
see
the same list of call records and will select any record and try to call
the
contact person for that record and edit the record. Now, my question is
how
do I prevent more than one user from selecting the same call record and
calling the same person?

Thanks in advance.

Mar 29 '06 #3

P: n/a
SP

"helpful sql" <no****@stopspam.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
Hi,
I am working on an app that will display the list of all scheduled call
records in our database to the users. All users of the application will
see
the same list of call records and will select any record and try to call
the
contact person for that record and edit the record. Now, my question is
how
do I prevent more than one user from selecting the same call record and
calling the same person?


I would question the design a little. A simple example will perhaps help.
You have someone on your list who is called Rajakanistaremd
Juditrixidisticad. I will appear on everyones list every day and because the
users can pick and choose who they call I can bet that a year will go by and
no one will call that person. Generally call lists are done 2 ways. One is
to assign calls to a particular user. This is done if follow up calls need
to be performed by the same user. The other is a "Next Call" scenario where
you have to call the name the system gives you. Then you can prioritize the
calls so that for example a certain region or demographic can be put to the
top of the list and the user has no choice but to call who you want. This
also avoids alot of the concurrency issues that occur when you display data
but immediately that data is out of date.

SP
Mar 29 '06 #4

This discussion thread is closed

Replies have been disabled for this discussion.