Who owns DBBINDING::pObject ?

Maxime LABELLE <[email protected]> Wed, 2 Apr 2003 11:44:42 +0200
Newsgroups	gmane.comp.windows.devel.oledb.devel
Message-ID	<[email protected]>
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C2F8FC.7DEB4394
Content-Type: text/plain;
        charset="iso-8859-1"

Hi,

I have found a strange behaviour while trying to bind column information
pertaining to BLOB values, with the Oracle OLEDB provider.

Basically, I allocate the DBBINDING array and one of its item's pObject
member using the ::CoTaskMemAlloc() call. When I call
IAccessor::GetBindings(), the returned array is allocated by the provider
but the pObject member is set to point to the same memory address that
was used initially when setting the binding information.

As a result, if I deallocate the pObject member after successfully calling
IAccessor::CreateAccessor(), the subsequent calls to
IAccessor::GetBindings()
retrieve a correct DBBINDING array but with a pObject member pointing to
the now invalid memory location!!

I can only get away with de-allocating the DBBINDING array, and not
the pObject members.

This goes against the MSDN documentations. I see that the ATL templates
do indeed deallocate this memory, but they never call
IAccessor::GetBindings()
subsequently. Besides, the allocation/deallocation is done via new and
delete.
Does that make a difference ?

Has anyone observed this behaviour?
Cheers.
Maxime.


You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.

------_=_NextPart_001_01C2F8FC.7DEB4394
Content-Type: text/html;
        charset="iso-8859-1"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1">
<META NAME="Generator" CONTENT="MS Exchange Server version 5.5.2650.12">
<TITLE>Who owns DBBINDING::pObject ?</TITLE>
</HEAD>
<BODY>

<P><FONT SIZE=2 FACE="Arial">Hi,</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I have found a strange behaviour while trying to bind column information</FONT>
<BR><FONT SIZE=2 FACE="Arial">pertaining to BLOB values, with the Oracle OLEDB provider.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Basically, I allocate the DBBINDING array and one of its item's pObject</FONT>
<BR><FONT SIZE=2 FACE="Arial">member using the ::CoTaskMemAlloc() call. When I call</FONT>
<BR><FONT SIZE=2 FACE="Arial">IAccessor::GetBindings(), the returned array is allocated by the provider</FONT>
<BR><FONT SIZE=2 FACE="Arial">but the pObject member is set to point to the same memory address that</FONT>
<BR><FONT SIZE=2 FACE="Arial">was used initially when setting the binding information.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">As a result, if I deallocate the pObject member after successfully calling</FONT>
<BR><FONT SIZE=2 FACE="Arial">IAccessor::CreateAccessor(), the subsequent calls to IAccessor::GetBindings()</FONT>
<BR><FONT SIZE=2 FACE="Arial">retrieve a correct DBBINDING array but with a pObject member pointing to</FONT>
<BR><FONT SIZE=2 FACE="Arial">the now invalid memory location!!</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">I can only get away with de-allocating the DBBINDING array, and not</FONT>
<BR><FONT SIZE=2 FACE="Arial">the pObject members.</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">This goes against the MSDN documentations. I see that the ATL templates</FONT>
<BR><FONT SIZE=2 FACE="Arial">do indeed deallocate this memory, but they never call IAccessor::GetBindings()</FONT>
<BR><FONT SIZE=2 FACE="Arial">subsequently. Besides, the allocation/deallocation is done via new and delete.</FONT>
<BR><FONT SIZE=2 FACE="Arial">Does that make a difference ?</FONT>
</P>

<P><FONT SIZE=2 FACE="Arial">Has anyone observed this behaviour?</FONT>
<BR><FONT SIZE=2 FACE="Arial">Cheers.</FONT>
<BR><FONT SIZE=2 FACE="Arial">Maxime.</FONT>
</P>

</BODY>
</HTML>
You can read messages from the OLEDB_DEV archive, unsubscribe from OLEDB_DEV,
or subscribe to other DevelopMentor lists at http://discuss.develop.com.
------_=_NextPart_001_01C2F8FC.7DEB4394--