Thomas G. Lockhart wrote:
> > At the moment, I'm stuck on a bizarre symptom (which of course will
> > make perfect sense the second after I send this e-mail :) I'm having
> > trouble seeing SQLExecute() entered, but can see the calling routine
> > and can see a return. So it looks like the routine is not actually
> > getting called, which of course is impossible. Don't know what is
> > going on quite yet...
>
> OK, with Gerald's guidance I can confirm that the linker was calling the
> iodbc routine SQLExecute rather than the internal psqlodbc routine of
> the same name. This makes a bit of sense to me, since iodbc is getting
> loaded first and is "steering the boat". I've stubbed-out SQLExecute()
> as has been done for several other routines by defining _SQLExecute() as
> the real routine and SQLExecute() as a pass-through stub.
>
I did that for SQLExecDirect but not SQLExecute, because SQLExecute wasn't
being called before the connection transitioned to a connected state,
whereas, SQLExecDirect was being called in the middle of transitioning to
the connected state, which was ultimately causing a runtime error.
I'm still confused though, why would this matter? I can understand for the
case I mentioned because of not being in the correct state, but what does it
matter if SQLExecute is called in the driver manager for normal execution.
That's how its supposed to work anyway. The application calls the driver
manager function, then the driver manager calls the function in one of its
loaded drivers.
Sounds like there is a lot more going on here than meets the eye. Or maybe
the Windows driver manager or the windows linking process is covering up
some things.
Byron