We are trying to include a module to access an oracle database from
our application which is written in C++ and built on windows with
visual studio 2005. The client we have found, OCI.dll is linked with
the runtime library built with the previous version of visual studio,
which in typical microsoft fashion, leads to random crashes when
closing connections. I have a hard time believing we are the only ones
trying to do this. Has anybody encountered and solved this issue?


Laurent

On Jun 26, 5:33 pm, laurent <laurento...@gmail.com> wrote:
> We are trying to include a module to access an oracle database from
> our application which is written in C++ and built on windows with
> visual studio 2005. The client we have found, OCI.dll is linked with
> the runtime library built with the previous version of visual studio,
> which in typical microsoft fashion, leads to random crashes when
> closing connections. I have a hard time believing we are the only ones
> trying to do this. Has anybody encountered and solved this issue?
>
> Laurent

I don't think the client ever existed of OCI.dll *alone*.
If you only have OCI.dll, you are just doomed.
You need to get a proper client. In 10g and higher, this can be an
instant one.

--
Sybrand Bakker
Senior Oracle DBA

On Jun 26, 11:42 am, sybrandb <sybra...@gmail.com> wrote:
> On Jun 26, 5:33 pm, laurent <laurento...@gmail.com> wrote:
>
> > We are trying to include a module to access an oracle database from
> > our application which is written in C++ and built on windows with
> > visual studio 2005. The client we have found, OCI.dll is linked with
> > the runtime library built with the previous version of visual studio,
> > which in typical microsoft fashion, leads to random crashes when
> > closing connections. I have a hard time believing we are the only ones
> > trying to do this. Has anybody encountered and solved this issue?
>
> > Laurent
>
> I don't think the client ever existed of OCI.dll *alone*.
> If you only have OCI.dll, you are just doomed.
> You need to get a proper client. In 10g and higher, this can be an
> instant one.
>
> --
> Sybrand Bakker
> Senior Oracle DBA


i have a complete client. i actually tried a few of them. Instant
client and the one delivered with oracle XE both include a dll
(OCI.dll) which depends on the wrong version of the miscrosoft
runtime library, and cause random failures of my application, when an
object allocated by the old runtime gets freed in the new runtime. My
application builds and runs most of the time but random crashes are a
show stopper.

Laurent

On Jun 26, 6:07 pm, laurent <laurento...@gmail.com> wrote:
> On Jun 26, 11:42 am, sybrandb <sybra...@gmail.com> wrote:
>
> (snip)
>
> i have a complete client. i actually tried a few of them. Instant
> client and the one delivered with oracle XE both include a dll
> (OCI.dll) which depends on the wrong version of the miscrosoft
> runtime library, and cause random failures of my application, when an
> object allocated by the old runtime gets freed in the new runtime. My
> application builds and runs most of the time but random crashes are a
> show stopper.
>
> Laurent

Thats why you don't allocate memory in one module and deallocate it in
another.
If the OCI.dll needs this, then it's a crappy interface. (Yes, I know,
not very helpful here, sorry.)
Maybe you can come up with a workaround where the memory stuff is kept
to each module.
You could post a few code snippets, maybe we find a path to the
light :-)

cheers,
Martin

On Jun 27, 7:56 am, "Martin T." <bilbothebagginsb...@freenet.de>
wrote:
> On Jun 26, 6:07 pm, laurent <laurento...@gmail.com> wrote:
>
> > On Jun 26, 11:42 am, sybrandb <sybra...@gmail.com> wrote:
>
> > (snip)
>
> > i have a complete client. i actually tried a few of them. Instant
> > client and the one delivered with oracle XE both include a dll
> > (OCI.dll) which depends on the wrong version of the miscrosoft
> > runtime library, and cause random failures of my application, when an
> > object allocated by the old runtime gets freed in the new runtime. My
> > application builds and runs most of the time but random crashes are a
> > show stopper.
>
> > Laurent
>
> Thats why you don't allocate memory in one module and deallocate it in
> another.

this is hard to do when a library returns a pointer to an object it
has allocated for you.

> If the OCI.dll needs this, then it's a crappy interface. (Yes, I know,
> not very helpful here, sorry.)
> Maybe you can come up with a workaround where the memory stuff is kept
> to each module.

working around stupid APIs is becoming the main part of my job since
the powers that be decided microsoft and oracle were the way to go.

> You could post a few code snippets, maybe we find a path to the
> light :-)
>
> cheers,
> Martin


I was hoping to use OTL, which gives me an agnostic layer on top of
different vendors' client libraries....

On Jun 27, 6:36 pm, laurent <laurento...@gmail.com> wrote:
> On Jun 27, 7:56 am, "Martin T." <bilbothebagginsb...@freenet.de>
> wrote:
>
>
>
>
>
> > On Jun 26, 6:07 pm, laurent <laurento...@gmail.com> wrote:
>
> > > On Jun 26, 11:42 am, sybrandb <sybra...@gmail.com> wrote:
>
> > > (snip)
>
> > > i have a complete client. i actually tried a few of them. Instant
> > > client and the one delivered with oracle XE both include a dll
> > > (OCI.dll) which depends on the wrong version of the miscrosoft
> > > runtime library, and cause random failures of my application, when an
> > > object allocated by the old runtime gets freed in the new runtime. My
> > > application builds and runs most of the time but random crashes are a
> > > show stopper.
>
> > > Laurent
>
> > Thats why you don't allocate memory in one module and deallocate it in
> > another.
>
> this is hard to do when a library returns a pointer to an object it
> has allocated for you.
>

Brrrr. :-) Well, maybe you can create a simple wrapper dll that links
to the same dll as the OCI.dll and supplies a ociFree(void*);
function, that just calls free() so that the correct one is used ...

> > If the OCI.dll needs this, then it's a crappy interface. (Yes, I know,
> > not very helpful here, sorry.)
> > Maybe you can come up with a workaround where the memory stuff is kept
> > to each module.
>
> working around stupid APIs is becoming the main part of my job since
> the powers that be decided microsoft and oracle were the way to go.
>

Well. If it'd be simple everyone could do it ... ;-)

good luck!
Martin