Re: [INTERFACES] iodbc interface on Unix

From: "Thomas G(dot) Lockhart" <lockhart(at)alumni(dot)caltech(dot)edu>
To: Byron Nikolaidis <byronn(at)insightdist(dot)com>
Cc: Aleksey Demakov <avd(at)gcom(dot)ru>, pgsql-interfaces(at)postgreSQL(dot)org, Gerald Gryschuk <ggryschuk(at)scf(dot)sk(dot)ca>
Subject: Re: [INTERFACES] iodbc interface on Unix
Date: 1998-08-20 05:05:31
Message-ID: 35DBAE9B.331FB800@alumni.caltech.edu
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-interfaces

> > 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

In response to

Browse pgsql-interfaces by date

  From Date Subject
Next Message Thomas G. Lockhart 1998-08-20 05:12:51 Re: [INTERFACES] Data types and binary data
Previous Message Matthew Hagerty 1998-08-20 02:37:17 Data types and binary data