> > I can confirm that the linker was calling the
> > iodbc routine SQLExecute rather than the internal psqlodbc routine
> > of the same name.
> 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?
> ..., 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.
Yeah, but the problem is that the loaded driver is trying to call an
internal routine, and instead is accidentally calling *back* to the
driver manager. I would guess that for every call made to the loaded
driver, the driver manager is not expecting any more of its code to
execute until control returns from the loaded driver routine.
> 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.
Yup.
- Tom
