Very Computer

I am using SqlServer 7.0 for a data entry application.  The application
has data entry module and search module.  There are 5 data entry
operator.  The main table is created with default values and each row
goes to a data entry operator to update rest of the fields.  Is there
anyway i can avoid sending the same record to more than one data entry
operator in sqlserver.  I know you can give a hint when you do a
sqlstatement.  When i tried looking for similar kind of thing in BOL, i
could'n find any.  May be i am looking in the wrong place.
If there is no mechanism in sqlserver to handle this, then i am
planning to keep a bit flag for each row and update the flag whenever
it goes to a data entry operator and update the flag back with the data
once the data entry operator complete data entry. But i need to
implement state management to work this login without any bug.  Is this
a right way of doing?

I would like someone to guide me in the right direction to proceed
further.

Thanks in advance
Ramesh

Sent via Deja.com http://www.deja.com/
Before you buy.

I am using SqlServer 7.0 for a data entry application.  The application
has data entry module and search module.  There are 5 data entry
operator.  The main table is created with default values and each row
goes to a data entry operator to update rest of the fields.  Is there
anyway i can avoid sending the same record to more than one data entry
operator in sqlserver.  I know you can give a hint when you do a
sqlstatement.  When i tried looking for similar kind of thing in BOL, i
could'n find any.  May be i am looking in the wrong place.
If there is no mechanism in sqlserver to handle this, then i am
planning to keep a bit flag for each row and update the flag whenever
it goes to a data entry operator and update the flag back with the data
once the data entry operator complete data entry. But i need to
implement state management to work this login without any bug.  Is this
a right way of doing?

I would like someone to guide me in the right direction to proceed
further.

Thanks in advance
Ramesh

Sent via Deja.com http://www.deja.com/
Before you buy.

Since the operator may go to lunch, or kill his application in some
disorderly way, the column should probably be a date column, and if
the value is more than, say, an hour ago, this is the same as that
the entry has not been handled yet. Then if the first operator
comes back from his lunch and presses the Update button in the
application, you need to check that someone has not come in between

Timestamp columns can be handy for the latter. Note that timestamp
in SQL Server has nothing to with time or date.

--