ADO initialization fails on W2003

OVERVIEW:
ADO initialization fails on W2003 Server, Standard Edition.
This is a new system.
This is the first time this app has been compiled or run on this system.
The app runs fine on all other servers I've tried it on.
What should I check?
Is anyone else able to run ADO routines against OLE 5.2?
Thanks,
Brad.
DETAILS:
OLE32.dll v.5.2.3790.250
OLEAUT32.dll v.5.2.3790.0
Tracing into the code, I get into
_WStrAsg("", "'ISAUTOINCREMENT'");
which calls SysReAllocStringLen. This fails with an access violation.
SysReAllocStringLen is a call into OLEAUT32.dll.
All the OLE32 dll look to be updated. They are newer than anything
on any of my XP systems.
I have a new test project that uses ADODB and it *doesn't* fail.
Yes, it does go through the same code just as nice as you could want.
The same app is deployed an running on dozens of other systems.
None are as new as this one.
So my guess is that it has to be something about the way the new
system is set up.
My next step is to start tearing down a copy of my project. But I'm
not terribly hopeful.
Thanks,
Brad.Long shot but is the bad project compiled on the same library as the working
one. Also, have you updated to the latest mdac + fixes.
-oj
"Brad White" <bwhite at inebraska . com> wrote in message
news:OQLP18vDFHA.2540@.TK2MSFTNGP09.phx.gbl...
> OVERVIEW:
> ADO initialization fails on W2003 Server, Standard Edition.
> This is a new system.
> This is the first time this app has been compiled or run on this system.
> The app runs fine on all other servers I've tried it on.
> What should I check?
> Is anyone else able to run ADO routines against OLE 5.2?
> Thanks,
> Brad.
> DETAILS:
> OLE32.dll v.5.2.3790.250
> OLEAUT32.dll v.5.2.3790.0
> Tracing into the code, I get into
> _WStrAsg("", "'ISAUTOINCREMENT'");
> which calls SysReAllocStringLen. This fails with an access violation.
> SysReAllocStringLen is a call into OLEAUT32.dll.
> All the OLE32 dll look to be updated. They are newer than anything
> on any of my XP systems.
> I have a new test project that uses ADODB and it *doesn't* fail.
> Yes, it does go through the same code just as nice as you could want.
> The same app is deployed an running on dozens of other systems.
> None are as new as this one.
> So my guess is that it has to be something about the way the new
> system is set up.
> My next step is to start tearing down a copy of my project. But I'm
> not terribly hopeful.
> --
> Thanks,
> Brad.
>
>
>|||Thanks for the reply.
The first thing I checked was MDAC, and yes it is 2.8.
I thought last night that perhaps it is a 2003 thing,
but no, we have had installations for months on 2003 Server
with no problems.
Same libraries. Tried the debug versions of the libraries in both exe's
with same results.
"oj" <nospam_ojngo@.home.com> wrote in message
news:uMArKKwDFHA.2032@.tk2msftngp13.phx.gbl...
> Long shot but is the bad project compiled on the same library as the
working
> one. Also, have you updated to the latest mdac + fixes.
> --
> -oj
>
> "Brad White" <bwhite at inebraska . com> wrote in message
> news:OQLP18vDFHA.2540@.TK2MSFTNGP09.phx.gbl...
>|||Brad,
Perhaps, reinstall the package?
-oj
"Brad White" <bwhite at inebraska . com> wrote in message
news:%23LzC%23$3DFHA.3924@.TK2MSFTNGP09.phx.gbl...
> Thanks for the reply.
> The first thing I checked was MDAC, and yes it is 2.8.
> I thought last night that perhaps it is a 2003 thing,
> but no, we have had installations for months on 2003 Server
> with no problems.
> Same libraries. Tried the debug versions of the libraries in both exe's
> with same results.
> --
> "oj" <nospam_ojngo@.home.com> wrote in message
> news:uMArKKwDFHA.2032@.tk2msftngp13.phx.gbl...
> working
>|||"oj" <nospam_ojngo@.home.com> wrote in message
news:u34aoVAEFHA.3732@.TK2MSFTNGP14.phx.gbl...
> Brad,
> Perhaps, reinstall the package?
>
Thanks for the reply.
The way it was acting reminded me of memory corruption,
but I couldn't see how that could be since no custom code
had run yet.
Turns out it was an unrelated dll improperly installed.
Reinstalling that to solve another problem, solved this problem.
It wasn't an ADO thing or WideStr thing at all.
--
Brad White

ADO erroring under VS2005 that don't occur under VS2003

I've tried posting this question to the C++ forum - but no solutions there...

The following code fragment works when compiled in VS2003 on both Windows XP Pro (32-bit) and WindowsXP Pro x64.

However, when compiled under VS2005, the call to 'pMyRecordsetPtr->RecordCount' fails on both 32bit and 64bit WindowsXP.

I have tried #import'ing msado20.tlb and msado27.tlb.

Has anybody had any similar experience?

HRESULT hr = ::CoInitialize(NULL);

if (FAILED(hr))

{

return false;

}

_ConnectionPtr pConnection;

hr = pConnection.CreateInstance(__uuidof(Connection));

if (FAILED(hr))

{

return false;

}

try

{

//

_bstr_t strConnectionString = "Provider=sqloledb;Server=server1;Database=db1" ;

pConnection->CursorLocation = adUseClient ;

pConnection->Open(strConnectionString,

_T("user"), _T("pwd"), -1);

_CommandPtr pCommand(__uuidof(Command));

pCommand->ActiveConnection = pConnection;

pCommand->CommandText = "MyStoreProcedure";

pCommand->CommandType = adCmdStoredProc;

_RecordsetPtr pRecordSet = pCommand->Execute( 0, 0, 0 ) ;

// This fails
long lNumRecs = pRecordSet->RecordCount ;

pRecordSet->Close();

pConnection->Close();

::CoUninitialize();

}

catch (_com_error &e)

{

::CoUninitialize();

// ...

}

Dear Chappers, I get an error also, but no solution, sorry

Ado.cpp

h:\src\alarmlogger_vc2005\alarmview\debugobj\msado15.tli(111) : error C2065: '_result' : undeclared identifier

ADO erroring under VS2005 that don't occur under VS2003

I've tried posting this question to the C++ forum - but no solutions there...

The following code fragment works when compiled in VS2003 on both Windows XP Pro (32-bit) and WindowsXP Pro x64.

However, when compiled under VS2005, the call to 'pMyRecordsetPtr->RecordCount' fails on both 32bit and 64bit WindowsXP.

I have tried #import'ing msado20.tlb and msado27.tlb.

Has anybody had any similar experience?

HRESULT hr = ::CoInitialize(NULL);

if (FAILED(hr))

{

return false;

}

_ConnectionPtr pConnection;

hr = pConnection.CreateInstance(__uuidof(Connection));

if (FAILED(hr))

{

return false;

}

try

{

//

_bstr_t strConnectionString = "Provider=sqloledb;Server=server1;Database=db1" ;

pConnection->CursorLocation = adUseClient ;

pConnection->Open(strConnectionString,

_T("user"), _T("pwd"), -1);

_CommandPtr pCommand(__uuidof(Command));

pCommand->ActiveConnection = pConnection;

pCommand->CommandText = "MyStoreProcedure";

pCommand->CommandType = adCmdStoredProc;

_RecordsetPtr pRecordSet = pCommand->Execute( 0, 0, 0 ) ;

// This fails
long lNumRecs = pRecordSet->RecordCount ;

pRecordSet->Close();

pConnection->Close();

::CoUninitialize();

}

catch (_com_error &e)

{

::CoUninitialize();

// ...

}

Dear Chappers, I get an error also, but no solution, sorry

Ado.cpp

h:\src\alarmlogger_vc2005\alarmview\debugobj\msado15.tli(111) : error C2065: '_result' : undeclared identifier