I am looking for expert advice regarding the simultaneous access one of our
production database.

In my database I have insert, update and select stored procedure and we have
registration database like people access that database simultaneously like
1000 users in 1 minute. We have one module called insert/update users and
other module is search. I am thinking in search stored procedure if I used
NOLOCK locking hint, this will solve my problem of searching, can anyone give
me expert advice on it.

Thanks

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote

You really haven't told us anything about what your problem you are trying
to solve is. If you are being blocked by the inserts and updates then a
NOLOCK will read the rows anyway but you will get dirty reads. A simple
insert and update should not block but for a few milliseconds at most so I
doubt that is the real problem. If the search select is constructed properly
and has appropriate indexes it should not be bothered that much by some
inserts or updates. But if any of these do not have proper indexes and you
have to scan tables that is another story.

--
Andrew J. Kelly SQL MVP
Solid Quality Mentors


"Rogers" <Rogers (AT) discussions (DOT) microsoft.com> wrote