ExecuteReader Blocks Inserts on a Table

[Charles Law]

I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[=?Utf-8?B?S2VycnkgTW9vcm1hbg==?=]

Charles,

Are the 2 applications on the same machine or different machines?

Is the database server on a different machine than the applications?

Kerry Moorman
"Charles Law" wrote:

I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Cor Ligthert[MVP]]

Charles,

You are by the way not using transaction locking, because then this is the
normal behaviour.

Cor

"Charles Law" <bl***@nowhere.comschreef in bericht
news:Om**************@TK2MSFTNGP06.phx.gbl...

>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the rows, writing them out to a file. This takes about 5 minutes until I
close the reader.

Whilst this is going on, I have another application that is trying to
insert rows into the table. Normally, the inserts happen straight away,
but when the reader is open each insert takes a very long time to
complete.

I realise that this is not an unreasonable thing to happen, given that I
am trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Jack Jackson]

On Thu, 19 Jun 2008 02:17:57 +0100, "Charles Law" <bl***@nowhere.com>
wrote:

>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

You might take a look at the Transact-SQL statement SET TRANSACTION
ISOLATION LEVEL.

[Tibor Karaszi]

If the SELECT limits itself using a WHERE clause to rows which aren't in the inserted set, then you
have a chance to have the SELECT not blocked by your INSERTs. But that also depends on what
execution plan you get. If SQL Server drive the SELECT using an index which is on something that can
be used to exclude the rows to INSERT then you shouldn't see this blocking. However, considering you
return so many rows, you need to carefully evaluate your indexing strategy as well as your SELECT
query to make this happen.

Other options include Snapshot isolation and the READPAST optimizer hint. Those are well documented
in Books Online.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message news:Om**************@TK2MSFTNGP06.phx.gbl...

>I have a sproc that returns data from a table using a simple SELECT. There are quite a few rows
returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the rows, writing them
out to a file. This takes about 5 minutes until I close the reader.

Whilst this is going on, I have another application that is trying to insert rows into the table.
Normally, the inserts happen straight away, but when the reader is open each insert takes a very
long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am trying to write to the
table whilst reading from it, but the rows being written will never be included in the WHERE
clause in my select statement, and even if they were (which they won't), I wouldn't want them
included in the selected rows.

Is there a way to read rows so that inserts can still occur without blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Charles Law]

Hi Kerry

The two applications are on different machines, connected by a fairly slow
link, which is why it takes so long to iterate through the rows returned by
the reader. The database server is clustered on another machine, which is on
a Gb link to the second application, but the first (reader) application is
at the other end of the slow connection.

I could run both on the same machine, but then I would have to transfer the
resulting file over the slow link, and that would take longer in real time.

Charles
"Kerry Moorman" <Ke**********@discussions.microsoft.comwrote in message
news:6A**********************************@microsof t.com...

Charles,

Are the 2 applications on the same machine or different machines?

Is the database server on a different machine than the applications?

Kerry Moorman
"Charles Law" wrote:

>I have a sproc that returns data from a table using a simple SELECT.
There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the
rows, writing them out to a file. This takes about 5 minutes until I
close
the reader.

Whilst this is going on, I have another application that is trying to
insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I
am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select
statement,
and even if they were (which they won't), I wouldn't want them included
in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Charles Law]

Hi Cor

No, I'm not explicitly using transaction locking. I thought, therefore, that
the reader would use row level locking, but if it is, it is still causing
some kind of locking problem.

Charles
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:1E**********************************@microsof t.com...

Charles,

You are by the way not using transaction locking, because then this is the
normal behaviour.

Cor

"Charles Law" <bl***@nowhere.comschreef in bericht
news:Om**************@TK2MSFTNGP06.phx.gbl...

>>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the rows, writing them out to a file. This takes about 5 minutes until I
close the reader.

Whilst this is going on, I have another application that is trying to
insert rows into the table. Normally, the inserts happen straight away,
but when the reader is open each insert takes a very long time to
complete.

I realise that this is not an unreasonable thing to happen, given that I
am trying to write to the table whilst reading from it, but the rows
being written will never be included in the WHERE clause in my select
statement, and even if they were (which they won't), I wouldn't want them
included in the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Charles Law]

Hi Jack

I did read up about this, but it suggested that the default is row level
locking, which seemed to be the one I'd want anyway, so I haven't attempted
to change it. I have just looked again, and I see there is more to this than
I first thought, so I will read up.

Cheers

Charles
"Jack Jackson" <jj******@cinnovations.netwrote in message
news:55********************************@4ax.com...

On Thu, 19 Jun 2008 02:17:57 +0100, "Charles Law" <bl***@nowhere.com>
wrote:

>>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to
insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I
am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

You might take a look at the Transact-SQL statement SET TRANSACTION
ISOLATION LEVEL.

[Charles Law]

Hi Tibor

Thanks for the reply. I hadn't thought about the indexing issue. I will add
these to my reading list.

Cheers

Charles
"Tibor Karaszi" <ti***************************@hotmail.nomail.comw rote in
message news:FC**********************************@microsof t.com...

If the SELECT limits itself using a WHERE clause to rows which aren't in
the inserted set, then you have a chance to have the SELECT not blocked by
your INSERTs. But that also depends on what execution plan you get. If SQL
Server drive the SELECT using an index which is on something that can be
used to exclude the rows to INSERT then you shouldn't see this blocking.
However, considering you return so many rows, you need to carefully
evaluate your indexing strategy as well as your SELECT query to make this
happen.

Other options include Snapshot isolation and the READPAST optimizer hint.
Those are well documented in Books Online.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message
news:Om**************@TK2MSFTNGP06.phx.gbl...

>>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the rows, writing them out to a file. This takes about 5 minutes until I
close the reader.

Whilst this is going on, I have another application that is trying to
insert rows into the table. Normally, the inserts happen straight away,
but when the reader is open each insert takes a very long time to
complete.

I realise that this is not an unreasonable thing to happen, given that I
am trying to write to the table whilst reading from it, but the rows
being written will never be included in the WHERE clause in my select
statement, and even if they were (which they won't), I wouldn't want them
included in the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

[Tibor Karaszi]

I did read up about this, but it suggested that the default is row level locking,

It is not that easy. First, SQL Server decided itself whether to lock row, page, or table level.
Factors involved in this decision is selectivity of query and concurrent users. Also, something that
start up as row level can during execution escalate to table level.

But even with row level, you are not helped if SQL Server need to look at every row. How do SQL
Server know if a row satisfy your criteria without looking at it first? See my other post for
elaboration about this topic.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message news:uE**************@TK2MSFTNGP04.phx.gbl...

Hi Jack

I did read up about this, but it suggested that the default is row level locking, which seemed to
be the one I'd want anyway, so I haven't attempted to change it. I have just looked again, and I
see there is more to this than I first thought, so I will read up.

Cheers

Charles
"Jack Jackson" <jj******@cinnovations.netwrote in message
news:55********************************@4ax.com...

>On Thu, 19 Jun 2008 02:17:57 +0100, "Charles Law" <bl***@nowhere.com>
wrote:

>>>I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

You might take a look at the Transact-SQL statement SET TRANSACTION
ISOLATION LEVEL.

[Charles Law]

Hi Tibor

Yes, I was obviously viewing this too simplistically. I have a couple of
Kalen Delaney's books, and there are some good topics in them that prove how
naive I was.

Cheers.

Charles
"Tibor Karaszi" <ti***************************@hotmail.nomail.comw rote in
message news:8A**********************************@microsof t.com...

>I did read up about this, but it suggested that the default is row level
locking,

It is not that easy. First, SQL Server decided itself whether to lock row,
page, or table level. Factors involved in this decision is selectivity of
query and concurrent users. Also, something that start up as row level can
during execution escalate to table level.

But even with row level, you are not helped if SQL Server need to look at
every row. How do SQL Server know if a row satisfy your criteria without
looking at it first? See my other post for elaboration about this topic.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message
news:uE**************@TK2MSFTNGP04.phx.gbl...

>Hi Jack

I did read up about this, but it suggested that the default is row level
locking, which seemed to be the one I'd want anyway, so I haven't
attempted to change it. I have just looked again, and I see there is more
to this than I first thought, so I will read up.

Cheers

Charles
"Jack Jackson" <jj******@cinnovations.netwrote in message
news:55********************************@4ax.com.. .

>>On Thu, 19 Jun 2008 02:17:57 +0100, "Charles Law" <bl***@nowhere.com>
wrote:

I have a sproc that returns data from a table using a simple SELECT.
There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the
rows, writing them out to a file. This takes about 5 minutes until I
close
the reader.

Whilst this is going on, I have another application that is trying to
insert
rows into the table. Normally, the inserts happen straight away, but
when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I
am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select
statement,
and even if they were (which they won't), I wouldn't want them included
in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles
You might take a look at the Transact-SQL statement SET TRANSACTION
ISOLATION LEVEL.

[Tibor Karaszi]

Yes, Kalen's books, along with Books Online and possibly some hints mentioned in this thread should
get you going on this. :-)

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message news:ug**************@TK2MSFTNGP06.phx.gbl...

Hi Tibor

Yes, I was obviously viewing this too simplistically. I have a couple of Kalen Delaney's books,
and there are some good topics in them that prove how naive I was.

Cheers.

Charles
"Tibor Karaszi" <ti***************************@hotmail.nomail.comw rote in message
news:8A**********************************@microsof t.com...

>>I did read up about this, but it suggested that the default is row level locking,

It is not that easy. First, SQL Server decided itself whether to lock row, page, or table level.
Factors involved in this decision is selectivity of query and concurrent users. Also, something
that start up as row level can during execution escalate to table level.

But even with row level, you are not helped if SQL Server need to look at every row. How do SQL
Server know if a row satisfy your criteria without looking at it first? See my other post for
elaboration about this topic.

--
Tibor Karaszi, SQL Server MVP
http://www.karaszi.com/sqlserver/default.asp
http://sqlblog.com/blogs/tibor_karaszi
"Charles Law" <bl***@nowhere.comwrote in message news:uE**************@TK2MSFTNGP04.phx.gbl...

>>Hi Jack

I did read up about this, but it suggested that the default is row level locking, which seemed
to be the one I'd want anyway, so I haven't attempted to change it. I have just looked again,
and I see there is more to this than I first thought, so I will read up.

Cheers

Charles
"Jack Jackson" <jj******@cinnovations.netwrote in message
news:55********************************@4ax.com. ..
On Thu, 19 Jun 2008 02:17:57 +0100, "Charles Law" <bl***@nowhere.com>
wrote:

>I have a sproc that returns data from a table using a simple SELECT. There
>are quite a few rows returned, e.g. ~150,000.
>
>In my first application, I use a reader on the sproc and iterate through the
>rows, writing them out to a file. This takes about 5 minutes until I close
>the reader.
>
>Whilst this is going on, I have another application that is trying to insert
>rows into the table. Normally, the inserts happen straight away, but when
>the reader is open each insert takes a very long time to complete.
>
>I realise that this is not an unreasonable thing to happen, given that I am
>trying to write to the table whilst reading from it, but the rows being
>written will never be included in the WHERE clause in my select statement,
>and even if they were (which they won't), I wouldn't want them included in
>the selected rows.
>
>Is there a way to read rows so that inserts can still occur without
>blocking?
>
>I am using VB.NET in VS2005, and SQL Server 2005.
>
>TIA
>
>Charles
>

You might take a look at the Transact-SQL statement SET TRANSACTION
ISOLATION LEVEL.

[Andrew Morton]

Charles Law wrote:

I have a sproc that returns data from a table using a simple SELECT.
There are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate
through the rows, writing them out to a file. This takes about 5
minutes until I close the reader.

If you are doing

while moreRecords
begin
read record
write record to file
end

then maybe the writing to disk is the slow step, so how about

while moreRecords
begin
read record
append record to stringbuilder
end
write stringbuilder to file

?

I take it getting the sp to write to a file is not an option?

Andrew

[Charles Law]

Hi Andrew

Because of the speed of the connection, I think the extended times are
simply because of the time it takes to transfer that many records down the
wire. The file write is almost certainly not the slow bit.

If the sproc were to create the file then it would end up server-side, and I
need it client-side. Copying it would take much longer than the current 5
minutes.

Charles
"Andrew Morton" <ak*@in-press.co.uk.invalidwrote in message
news:6b*************@mid.individual.net...

Charles Law wrote:

>I have a sproc that returns data from a table using a simple SELECT.
There are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate
through the rows, writing them out to a file. This takes about 5
minutes until I close the reader.

If you are doing

while moreRecords
begin
read record
write record to file
end

then maybe the writing to disk is the slow step, so how about

while moreRecords
begin
read record
append record to stringbuilder
end
write stringbuilder to file

?

I take it getting the sp to write to a file is not an option?

Andrew

[=?ISO-8859-1?Q?G=F6ran_Andersson?=]

Charles Law wrote:

I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

As already has been mentioned, there is different levels of locking. As
you are reading so many lines, the row locks will probably escalate into
page locks or a table lock to preserve resources. When that happens, it
will also lock other rows than the ones that you have selected.

You can specify (ROWLOCK) in your query. That should keep the database
from escalating the locks.

--
Göran Andersson
_____
http://www.guffa.com

[Alex Kuznetsov]

On Jun 18, 8:17 pm, "Charles Law" <[e-mail]:

I have a sproc that returns data from a table using a simple SELECT. There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through the
rows, writing them out to a file. This takes about 5 minutes until I close
the reader.

Whilst this is going on, I have another application that is trying to insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select statement,
and even if they were (which they won't), I wouldn't want them included in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

Consider using snapshot isolation, so that readers do not block
writers.

[Charles Law]

Hi Göran

Thanks for the tip. That fits in with what I am seeing. I will give it a
try.

Charles
"Göran Andersson" <gu***@guffa.comwrote in message
news:eU**************@TK2MSFTNGP05.phx.gbl...

Charles Law wrote:

>I have a sproc that returns data from a table using a simple SELECT.
There are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the rows, writing them out to a file. This takes about 5 minutes until I
close the reader.

Whilst this is going on, I have another application that is trying to
insert rows into the table. Normally, the inserts happen straight away,
but when the reader is open each insert takes a very long time to
complete.

I realise that this is not an unreasonable thing to happen, given that I
am trying to write to the table whilst reading from it, but the rows
being written will never be included in the WHERE clause in my select
statement, and even if they were (which they won't), I wouldn't want them
included in the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

As already has been mentioned, there is different levels of locking. As
you are reading so many lines, the row locks will probably escalate into
page locks or a table lock to preserve resources. When that happens, it
will also lock other rows than the ones that you have selected.

You can specify (ROWLOCK) in your query. That should keep the database
from escalating the locks.

--
Göran Andersson
_____
http://www.guffa.com

[Charles Law]

Hi Alex

I have just been reading about snapshot isolation and it also looks like a
likely candidate, as are some of the other suggestions.

Thanks.

Charles
"Alex Kuznetsov" <al****@gmail.comwrote in message
news:f5**********************************@a70g2000 hsh.googlegroups.com...

On Jun 18, 8:17 pm, "Charles Law" <[e-mail]:

>I have a sproc that returns data from a table using a simple SELECT.
There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the
rows, writing them out to a file. This takes about 5 minutes until I
close
the reader.

Whilst this is going on, I have another application that is trying to
insert
rows into the table. Normally, the inserts happen straight away, but when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I
am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select
statement,
and even if they were (which they won't), I wouldn't want them included
in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles

Consider using snapshot isolation, so that readers do not block
writers.

[Cor Ligthert[MVP]]

Charles,

I thought that I had read once from William Vaughn that in fact the
datareader is processing a big resultset, which is simply build in one time.
Therefore the problem seems strange for me.

Try it in the AdoNet newsgroup, this is honey for Bill.

Cor

"Charles Law" <bl***@nowhere.comschreef in bericht
news:Oa**************@TK2MSFTNGP05.phx.gbl...

Hi Kerry

The two applications are on different machines, connected by a fairly slow
link, which is why it takes so long to iterate through the rows returned
by the reader. The database server is clustered on another machine, which
is on a Gb link to the second application, but the first (reader)
application is at the other end of the slow connection.

I could run both on the same machine, but then I would have to transfer
the resulting file over the slow link, and that would take longer in real
time.

Charles
"Kerry Moorman" <Ke**********@discussions.microsoft.comwrote in message
news:6A**********************************@microsof t.com...

>Charles,

Are the 2 applications on the same machine or different machines?

Is the database server on a different machine than the applications?

Kerry Moorman
"Charles Law" wrote:

>>I have a sproc that returns data from a table using a simple SELECT.
There
are quite a few rows returned, e.g. ~150,000.

In my first application, I use a reader on the sproc and iterate through
the
rows, writing them out to a file. This takes about 5 minutes until I
close
the reader.

Whilst this is going on, I have another application that is trying to
insert
rows into the table. Normally, the inserts happen straight away, but
when
the reader is open each insert takes a very long time to complete.

I realise that this is not an unreasonable thing to happen, given that I
am
trying to write to the table whilst reading from it, but the rows being
written will never be included in the WHERE clause in my select
statement,
and even if they were (which they won't), I wouldn't want them included
in
the selected rows.

Is there a way to read rows so that inserts can still occur without
blocking?

I am using VB.NET in VS2005, and SQL Server 2005.

TIA

Charles