first user liberates

When an user opens any form to alter some given, if or user to open the same
screen and to try to consult the same registration everything is joined
until that the first user liberates. However, the times an user is in the
office and the other in the branch, the second is without to know that is
happening and it ends up giving Crt+Alt_Dell and closes in the the
application horns.
I am discussing with the company that developed the system telling them that
that could not happen and that if two users try to open the same
registration the second it should receive at least a message informing that
has somebody using or you simply let him to open only reading.
They say that doesn't have way and that have to guide the users they not to
leave her the open screens without use. I found this answer a tremendous
lack of good sense. I am trying to look for a more coherent answer for the
problem, because I don't believe that a group of data relational works in
that way. I am convinced that the programming technique used by them and
that is wrong. Somebody could talk about the subject<< I am trying to look for a more coherent answer for the problem >>
And we are trying to look for a more coherent description of the problem...
"Frank Dulk" <fdulk@.bol.com.br> wrote in message
news:Onx0PaAtFHA.912@.TK2MSFTNGP11.phx.gbl...
> When an user opens any form to alter some given, if or user to open the
> same
> screen and to try to consult the same registration everything is joined
> until that the first user liberates. However, the times an user is in the
> office and the other in the branch, the second is without to know that is
> happening and it ends up giving Crt+Alt_Dell and closes in the the
> application horns.
> I am discussing with the company that developed the system telling them
> that
> that could not happen and that if two users try to open the same
> registration the second it should receive at least a message informing
> that
> has somebody using or you simply let him to open only reading.
> They say that doesn't have way and that have to guide the users they not
> to
> leave her the open screens without use. I found this answer a tremendous
> lack of good sense. I am trying to look for a more coherent answer for the
> problem, because I don't believe that a group of data relational works in
> that way. I am convinced that the programming technique used by them and
> that is wrong. Somebody could talk about the subject
>|||From what I understand you're saying that you'd like to implement some sort
of entity-locking in your database. There are many solutions to this problem,
but since this is the 21st century after all, you might look into what
experts say about the 'smart client'. Google for that or look it up on MSDN.
Entity-locking involves a special functionality in a database that helps
prevent concurrency conflicts. Do not confuse it with the locking options
provided by the SQL server. Usually you can achieve entity-locking by keeping
record of all entities that are being processed at any given time by a user.
Example: in a document management system - if a document is checked out by an
editor, all the rows in all the tables in that system become "off-limits"
(read-only) to any other user. This feature is not natively supported by MS
SQL Server, but it can be added. Usually it's called something like
'check-out managmenet' or the like.
ML|||It appears that the company that developed the system used pessimistic
concurrency instead of optimistic concurrency. While pessimistic
concurrency is useful in some circumstances, it is generally not appropriate
for data entry screens. With pessimistic concurrency, the rows are locked
as they are read out, and the locks are held until the transaction commits.
With optimistic concurrency, the rows are read out, but locks are not held.
Instead, the contents of the rows are checked against the original contents,
and if they're different, then a collision occurred--meaning that another
transaction changed a row.
"Frank Dulk" <fdulk@.bol.com.br> wrote in message
news:Onx0PaAtFHA.912@.TK2MSFTNGP11.phx.gbl...
> When an user opens any form to alter some given, if or user to open the
same
> screen and to try to consult the same registration everything is joined
> until that the first user liberates. However, the times an user is in the
> office and the other in the branch, the second is without to know that is
> happening and it ends up giving Crt+Alt_Dell and closes in the the
> application horns.
> I am discussing with the company that developed the system telling them
that
> that could not happen and that if two users try to open the same
> registration the second it should receive at least a message informing
that
> has somebody using or you simply let him to open only reading.
> They say that doesn't have way and that have to guide the users they not
to
> leave her the open screens without use. I found this answer a tremendous
> lack of good sense. I am trying to look for a more coherent answer for the
> problem, because I don't believe that a group of data relational works in
> that way. I am convinced that the programming technique used by them and
> that is wrong. Somebody could talk about the subject
>|||Rather than utilizing record locking, you can query the current datetime
when the user opens a form. When the form is submitted, it can confirm if
form datetime > the row's LastUpdated datetime. If so, then update the row
and LastUpdated. In the even that the row has been updated by another user
while the form was open (form datetime < LastUpdated), then let the end
user's decide (from a high level workflow perspective) what should take
place. Whatever, they decide is valid; it's their system. As a DBA, your
responsibility is to insure that referential integrity of the database is
intact, but this specific type of situation should not concern that.
"Frank Dulk" <fdulk@.bol.com.br> wrote in message
news:Onx0PaAtFHA.912@.TK2MSFTNGP11.phx.gbl...
> When an user opens any form to alter some given, if or user to open the
> same
> screen and to try to consult the same registration everything is joined
> until that the first user liberates. However, the times an user is in the
> office and the other in the branch, the second is without to know that is
> happening and it ends up giving Crt+Alt_Dell and closes in the the
> application horns.
> I am discussing with the company that developed the system telling them
> that
> that could not happen and that if two users try to open the same
> registration the second it should receive at least a message informing
> that
> has somebody using or you simply let him to open only reading.
> They say that doesn't have way and that have to guide the users they not
> to
> leave her the open screens without use. I found this answer a tremendous
> lack of good sense. I am trying to look for a more coherent answer for the
> problem, because I don't believe that a group of data relational works in
> that way. I am convinced that the programming technique used by them and
> that is wrong. Somebody could talk about the subject
>