Very Computer

> We've got 7.0 running on NT 4.0 and we're running into a problem where it
> appears the users are hitting a web page that submits a query to the db
> and
> then get impatient - so they hit the stop button on the browser.  We're
> using the MS jdbc driver to hit SQL Server from Java Servlets and all of
> the web processes seem to handle this fairly cleanly, but on the db
> machine we zoom from using 3% of the cpus (dual cpu box) to using 50% or
> better.
> Needless to say everything slows quite a bit at that point.  Interestingly
> enough there is no disk activity going on so it's not as if SQL Server is
> working like mad through some series of large tables.  Anyone else heard
> of
> anything like this?  If so does moving to SQL 2000 and applying the
> service
> packs help?  Came across a few articles in the knowledge base that showwed
> sql serevr going into an ifinite loop for other conditions and in several
> of the cases the answer was to get to SQL 2000 with sp 2, but I'd like to
> get some comments from anyone in the field that has faced this before we
> go spend the money.

> Thanks.

> Rich Mycroft

>OK. solved this.  Had to do with the way we were using a series of temp
>tables and at one point doing an insert into one of the temp tables while
>doing a NOT IN subselect to try to make sure we weren't inserting
>duplicates.  Evidently the system decided to re-build the elements of the
>NOT IN after each row was inserted from the outer SQL resulting in a *
>little cpu sucker.  Used another temp table to permit me to delete matches
>from the first temp table out of the second one followed by doing an insert
>into the first thereby dropping the NOT IN bit. Works just fine.

>> We've got 7.0 running on NT 4.0 and we're running into a problem where it
>> appears the users are hitting a web page that submits a query to the db
>> and
>> then get impatient - so they hit the stop button on the browser.  We're
>> using the MS jdbc driver to hit SQL Server from Java Servlets and all of
>> the web processes seem to handle this fairly cleanly, but on the db
>> machine we zoom from using 3% of the cpus (dual cpu box) to using 50% or
>> better.
>> Needless to say everything slows quite a bit at that point.  Interestingly
>> enough there is no disk activity going on so it's not as if SQL Server is
>> working like mad through some series of large tables.  Anyone else heard
>> of
>> anything like this?  If so does moving to SQL 2000 and applying the
>> service
>> packs help?  Came across a few articles in the knowledge base that showwed
>> sql serevr going into an ifinite loop for other conditions and in several
>> of the cases the answer was to get to SQL 2000 with sp 2, but I'd like to
>> get some comments from anyone in the field that has faced this before we
>> go spend the money.

>> Thanks.

>> Rich Mycroft