• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 1773
  • Last Modified:

Pervasive SQL ODBC Keeps crashing w3wp.exe

I run a web service on a Windows Server 2003 SP2 box running ASP.net 2.0 accessing Pervasive 9.71.10.0 via ODBC.

I have several installations with a similar configuration but on this particular one, it seems that when more than one person tries to access the Web service at a time I get an IIS Worker Process - error (see attachment) This shuts down the ODBC connection to Pervasive SQL for a time, and then without intervention it will start working again.

There is a variance from this installation compared to all of my working installations, as follows:

On this installation IIS is running on the Pervasive server, on all other installation I have used two separate machines.  So normally I specify the ip address of the data server in my connection string.  For this one I am using 127.0.0.1.  

Also because I normally use 2 machine on the network to accomplish this connection I normally have a DSN Client ODBC interface on the IIS Server and an DSN Engine ODBC Interface on the Data server.  So on this installation I am only using the DSN Engine ODBC Interface.

The other thing that this installation has that others do not is large records compared to the other installations.  200000 records compared to 20000.

The error points me to some log files that do not exist:
accompat.txt and w3wp.exe.mdmp they are supposed to be in my profile's directory.

This is from the system event viewer:
The system has called a custom component and that component has failed and generated an exception. This indicates a problem with the custom component. Notify the developer of this component that a failure has occurred and provide them with the information below.
Component Prog ID: 1[ODBC][Env ea814e8]
Method Name: IDispenserDriver::CreateResource
Process Name: w3wp.exe
Exception: C0000005
Address: 0x0EBF37BA
Call Stack:
w3odbcci!ConnectDlg + 0xffea
 + 0x190aaf5






odbcerror.jpg
0
bcolladay
Asked:
bcolladay
2 Solutions
 
bcolladayAuthor Commented:
here are the server properties for memory etc.
serverprops1.jpg
serverprops2.jpg
0
 
bcolladayAuthor Commented:
There are about 16GB of DAT files on this server.  Some of which are up to to 2 to 4 GB alone.  I am not normally accessing these big files, but I do query a couple in a join that are a combined 400MB.
0
 
meverestCommented:
Hi,

it's a fault in the odbc connector dll - you need to contact the vendor for support.  There is nothing that amyone else can do about it :-(

Cheers.
0
Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

 
mirtheilCommented:
A few questions:
- What is the connection string being used by the crashing system?  
- You said that it seems that the second user gets the error.  Does it always happen on the second user?  
- The minidump seems to indicate a problem on the connect.  Is that where you are seeing the crash?  
- Is there anything in the PVSW.LOG?  

I don't think the query itself is causing the problem.
0
 
bcolladayAuthor Commented:
Here is the log file, the two entires in there may be unrelated, earlier in the day I was trying to run an update query and I "canceled" it twice.
pvsw.log
0
 
bcolladayAuthor Commented:
Here is my connection string:
Dsn=PDSData2;servername=192.168.0.244.1583;serverdsn=PDSDATA;arrayfetchon=1;arraybuffersize=8;transporthint=TCP:SPX;decimalsymbol=.;clientversion=9.71.10.0;codepageconvert=1252;

PDSData2 is the name if the Client DSN Interface on the webserver which is also the Pervasive server.  When I created that Client interface I used the ip address instead of the server name.  

PDSDATA is the Dataset set I am accessing on the pervasive server.

I thought I had it fixed yesterday, I originally only had the Engine DSN interface and was referencing it in the Connection string.  So I created a Client DSN Interface on the same machine and I referenced it.  All day long I was able to access it with at least 4 close-to simultaneous users.

I can't say for sure this is caused by multiple users, just that every time it happens it seems two people were accessing it around that time.  This morning when it crashed I was just accessing it with two separate computers, I was able to do two semi-simultaneous accesses but on the third one, only the first one went through.

I was able to get the accompat.txt and hdmp files this time by copying them before I sent the eroor report to microsoft.  I have attached it.

Again the only thing different between this and my other installations is that this server is a shared web-server and Pervasive server, where usually they are separate servers.  Also I think this is a virtual instance of windows 2003.
manifest.zip
0
 
bcolladayAuthor Commented:
This seems to have the most information about the crash from the hdmp file
error-part.txt
0
 
bcolladayAuthor Commented:
After the crash first thing this morning, it resets itself as usual and became available again after about 45 minutes.


Now, like yesterday, I can't crash it even hitting it four sessions at a time.
0
 
bcolladayAuthor Commented:
New error today
deperror.jpg
0
 
bcolladayAuthor Commented:
the detail from this error
deperror-detail.jpg
0
 
bcolladayAuthor Commented:
here are the new hdmp files
Errordumpfiles.zip
0
 
bcolladayAuthor Commented:
...also it was doing this before on 9.52 so I had them upgrade to 9.71.  No change.
0
 
Bill BachPresidentCommented:
All of your crashes indicate that the problem is happening within the Pervasive components, either W3ODBCCI.DLL or W3CSM###.DLL.  The most likely causes of this are some sort of memory overrun, and the DEP warning is a good thing, in this case.

You can first try to disable DEP for the various Pervasive components -- thismay allow it to continue running.  However, the memory overwrite will likely continue.  

What I would NEXT suggest is to look at your application and the database calls that it is making.  Are you calling any stored procedures or functions?  If so, review all of your data types within those procs and functions and verify that all data typing and conversions are hard-coded -- NEVER allow the PSQL engine to dynamically modify your types.

If you are NOT doing any SP's, then look instead at your queries.  Are you comparing different data types?  Even comparing numeric data of different types can cause an implicit conversion, and can cause problems.

The next option -- and we're running out of ways to analyze this -- would be to enable either ODBC tracing or the SQL Query Plan on the DSN, then letting the system run until it fails.  This is NOT the best option, as either will have a performance impact (ODBC tracing is severe impact, Query Plan is slight impact), but it will tell you where the failure occurs (at the end of the log).  

If that's not possible, then it may be better to split the database engine onto its own server, and use a network trace tool to capture the queries (going to TCP port 1583).

Finally, as you may be aware, PSQLv9 has been unsupported since the beginning of 2010.  If there is a bug in the Pervasive components, they are NOT going to fix it.  I would instead recommend moving to PSQLv10 (or the upcoming PSQLv11) and see if you can duplicate the problem there.  If so, then you'll want to log a formal support ticket with Pervasive, so that they can fix it.  Again, they won't fix it in v9, but knowing that it's fixed in a newer version would help improve your changes of finding it fixed when you upgrade.
0
 
bcolladayAuthor Commented:
Thanks Bill, I'm on vacation but I will check into some of these things when I get back in.
0
 
bcolladayAuthor Commented:
What I ended up doing was a setting the Application pool in IIS.  The Recycle worker process was set to recycle every 90 minutes.  I checked my other installs where I've never had this problem and they were set for every 29 hours.  This also seemed strange so I set this one to recycle twice a day, once at 1 am, and again at 5:00 am.  This has stopped the crashing.  I don't fully understand why, but it has.
0
 
bcolladayAuthor Commented:
Most of the suggestions while not the solutions led me to dig deeper into the system and led me to the final slef-solution
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Improve Your Query Performance Tuning

In this FREE six-day email course, you'll learn from Janis Griffin, Database Performance Evangelist. She'll teach 12 steps that you can use to optimize your queries as much as possible and see measurable results in your work. Get started today!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now