Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Provider error '8007000e' - HELP!!!

161 views
Skip to first unread message

Matt Pasiewicz

unread,
Aug 19, 1998, 3:00:00 AM8/19/98
to
Any assitance would be GREATLY appreciated.

I'm getting the following error at peak times on our site,
and I have no clue how to eliminate it.

-----------------------------------------------

Provider error '8007000e'

Not enough storage is available to complete this operation.

/ipage/SearchAction.asp, line 948

------------------------------------------------

Has anyone out there encountered this before?
I've not been able to find any information on Microsoft's site
about it. Any recommendations would be greatly appreciated.

I'm running IIS 4 on a nice, high performance machine ... The
server is not running close to peak utilization for memory or
processor speed. The same goes for the box we run our SQL
Server on.

The pages are performing queries to SQL Server 6.5 database.
We work with large recordsets, but the site performs fast, even
at peak times ... we've just recently been getting this error, and
all to frequently.

Please email any suggestions to:
ma...@ingrambook.com

Thanks for your help!

Ricardo

unread,
Aug 20, 1998, 3:00:00 AM8/20/98
to
We have the EXACTLY the same problems you are having, but haven't been able
to find information about it. Please, if you find any solutions, let me
know. I will do the same if I find something!

Ricardo Aponte-Yunqué
rap...@nstech.net

Matt Pasiewicz

unread,
Aug 20, 1998, 3:00:00 AM8/20/98
to
I've heard back from Microsoft .... although it doesn't apply to me, and
it's not exactly same error message, (and I'm not using Index Server) maybe
it will for you.

SYMPTOMS
> ========

When you do a query using Index Server, the browser may
return an error
message similar to the following:

Not enough storage is available to complete this operation

0x8007000e.

This error message will appear some of the time, but not necessarily
all of the time.

CAUSE
> =====

If the query is using a POST command (in the HTML file), you can get
the above error message. The Index Server is expecting all POST
commands to be Null Terminated.

WORKAROUND
> ==========

Instead of using the POST command, use the GET command in the HTML
code, or ensure that the data in the POST command is Null Terminated.


Ricardo wrote in message ...

za...@intrapreneur.org

unread,
Aug 21, 1998, 3:00:00 AM8/21/98
to
I ran into this error on a small project that uses Access. After looking at
everything imaginable (all ADO objects were closed and set to nothing, etc.) I
noticed that the ODBC driver seemed to have a memory leak. I don't know if it
was the OLEDB-ODBC provider, or the ODBC driver, but each connection seemed to
eat around 8K. I switched to the OLEDB driver for JET, the one recently
released with MDAC2, and PRESTO! the problem disappeared. Providers are also
included for SQL Server, and for Oracle. Although the literature says that it
was tested on Oracle 7.3, I've been using it with 7.1 with no problems.

zane

In article <e8lb6P9...@uppssnewspub04.moswest.msn.net>,

> &#137;

-----== Posted via Deja News, The Leader in Internet Discussion ==-----
http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

Matt Pasiewicz

unread,
Sep 3, 1998, 3:00:00 AM9/3/98
to
Zane, thanks for the info. Last week I added it to one of our production
servers.
Things are looking up.

Brad, if nothing else, its helped. After much time and distress, we brought
in
some consutants for an architectural overview. We discovered some
ineffcient
code ... not closing recordsets/connections, opening unneeded connections,
etc.
This will help us longterm. We also made a registry change to use free
threading
instead of apartment threading which appeared to help eliminate the errors
short term.
We did this before adding the MDAC 2 piece. You can check the following URL
for more info:
http://www.microsoft.com/data/reference/wp2/dagoniis_perf1_0g56.htm

Additionally, we found that we may not have been utilizing connection
pooling with SQL Server.
The article was for IIS 3, but the interesting part was the section on "SQL
Server Performance
and Stability with Connection Pooling" We were using Named Pipes instead of
TCP/IP.
See the following URL for more info:
http://premium.microsoft.com/msdn/library/partbook/asp/html/enablingconnecti
onpooling.htm

Finally, we discovered something called "disconnected recordsets" which we
believe will
help us longterm ... unfortunately, I can't recall where we found that
information, but
thought it might prove insightful. (KB Article ID: Q184397 - ?) We haven't
implemented it
yet, but it sounds interesting.

Hope this helps...

Matt Pasiewicz, Internet Project Manager
Ingram Customer Systems
http://www.ingrambook.com
One Ingram Blvd · LaVergne, TN USA 37086
voice: 800.793.5000 x5144
fax: 615.793.3976

-------------------------------------------------


>I ran into this error on a small project that uses Access. After looking
at
>everything imaginable (all ADO objects were closed and set to nothing,
etc.) I
>noticed that the ODBC driver seemed to have a memory leak. I don't know if
it
>was the OLEDB-ODBC provider, or the ODBC driver, but each connection seemed
to
>eat around 8K. I switched to the OLEDB driver for JET, the one recently
>released with MDAC2, and PRESTO! the problem disappeared. Providers are
also
>included for SQL Server, and for Oracle. Although the literature says that
it
>was tested on Oracle 7.3, I've been using it with 7.1 with no problems.

>zane

-----== Posted via Deja News, The Leader in Internet Discussion ==-----


http://www.dejanews.com/rg_mkgrp.xp Create Your Own Free Member Forum

> -----Original Message-----
> From: brad-vossler [mailto:brad-v...@sandhills.com]
> Sent: Thursday, September 03, 1998 9:15 AM
> To: ma...@ingrambook.com
> Subject: Your SQL/ASP errors
>
>
>
> I read your newsgroup posting on your error:


> Provider error '8007000e'
> Not enough storage is available to complete this operation.
> /ipage/SearchAction.asp, line 948
>

> We are having the EXACT same problem here. Have you found a
> solution yet?
> Did you try the solution Zane posted back to you?
>
> Thank you,
> -Brad Vossler

0 new messages