W3DBSMGR.EXE - Referenced memory could not be read

  • Follow


This is getting to be a real head scratcher.

I'm using the Pervasive SQL V8 SP1 Workgroup Engine on a Win2K Pro
workstation.

When I start getting more complicated with a column formula in a SELECT
statement, I get a crash that is, well ... rather pervasive:

w3dbsmgr.exe - Application Error : The instruction at "0x00a9c024"
referenced memory at "0x00000024". The memory could not be "read".

I've gone through uninstalls and reinstalls ensuring that Windows File
Protection (SFC) doesn't complain about any of the ODBC-related DLLs (or
other DLLs). The only fallout left, and I can't figure out a workaround or
locate the "offending" file, is ds32gt.dll (v 3.520.7713.0 keeps getting
downgraded to V3.520.7400.0).

The crash seems to rear its ugly head only when I construct a rather lengthy
series of CONVERT, SUBSTRING, MIN (or MAX), TIMESTAMPDIFF and SUM commands
together to translate a minimum and maximum decimal date down to SQL_DATE
form, determine the number of months between the two dates and divide that
result into the SUM value.

I've also been able to generate the crash working with a single MIN or MAX
date and leaving out the TIMESTAMPDIFF calculation and (obviously) SUM
value.

But if I want to do a "simple" translation from a decimal date to an
SQL_DATE date on a row-by-row basis (forget about all the other stuff), I
can get it to work without crashing.

Any ideas on why I'm getting the crash?

Better yet, any ideas on how to fix up WGE so it doesn't crack under
pressure?


0
Reply MyndPhlyp 1/10/2004 2:57:37 PM

First, remember that SP1 is NOT the current release of Pervasive.SQL V8.  There
was a set of hotfixes released for the SP1 version at the same time that V8.5
was released (October, 2003).  Try updating to either Hotfixes or (even better)
V8.5.  Get the patches for free from www.pervasive.com.

As for your query, it may just be a bug in the SQL engine.  I'd recommend
opening an incident with Pervasive tech support, providing the query and your
sample data set, so that they can duplicate the problem in-house and resolve it
for you.
 Goldstar Software Inc.
 Building on Btrieve(R) for the Future(SM)
 Bill Bach
 BillBach@goldstarsoftware.com
 http://www.goldstarsoftware.com
 *** Pervasive.SQL Service & Support Classes ***
 Chicago: March, 2004: See our web site for details!


MyndPhlyp wrote:

> This is getting to be a real head scratcher.
>
> I'm using the Pervasive SQL V8 SP1 Workgroup Engine on a Win2K Pro
> workstation.
>
> When I start getting more complicated with a column formula in a SELECT
> statement, I get a crash that is, well ... rather pervasive:
>
> w3dbsmgr.exe - Application Error : The instruction at "0x00a9c024"
> referenced memory at "0x00000024". The memory could not be "read".
>
> I've gone through uninstalls and reinstalls ensuring that Windows File
> Protection (SFC) doesn't complain about any of the ODBC-related DLLs (or
> other DLLs). The only fallout left, and I can't figure out a workaround or
> locate the "offending" file, is ds32gt.dll (v 3.520.7713.0 keeps getting
> downgraded to V3.520.7400.0).
>
> The crash seems to rear its ugly head only when I construct a rather lengthy
> series of CONVERT, SUBSTRING, MIN (or MAX), TIMESTAMPDIFF and SUM commands
> together to translate a minimum and maximum decimal date down to SQL_DATE
> form, determine the number of months between the two dates and divide that
> result into the SUM value.
>
> I've also been able to generate the crash working with a single MIN or MAX
> date and leaving out the TIMESTAMPDIFF calculation and (obviously) SUM
> value.
>
> But if I want to do a "simple" translation from a decimal date to an
> SQL_DATE date on a row-by-row basis (forget about all the other stuff), I
> can get it to work without crashing.
>
> Any ideas on why I'm getting the crash?
>
> Better yet, any ideas on how to fix up WGE so it doesn't crack under
> pressure?

0
Reply Bill 1/12/2004 11:09:27 AM


1 Replies
316 Views

(page loaded in 0.056 seconds)

Similiar Articles:











7/24/2012 8:56:39 PM


Reply: