Sender: tgl@mythos.jpl.nasa.gov
Message-ID: <35DB06BB.16F5D38D@alumni.caltech.edu>
Date: Wed, 19 Aug 1998 17:09:15 +0000
From: "Thomas G. Lockhart" <lockhart@alumni.caltech.edu>
Organization: Caltech/JPL
MIME-Version: 1.0
To: Byron Nikolaidis <byronn@insightdist.com>, Aleksey Demakov <avd@gcom.ru>
CC: pgsql-interfaces@postgreSQL.org, Gerald Gryschuk <ggryschuk@scf.sk.ca>
Subject: Re: [INTERFACES] iodbc interface on Unix
References: <35D99896.DFB21123@alumni.caltech.edu>
	<35D9D132.4DE6ACB8@insightdist.com> <86iujpr0qh.fsf@avd.gcom.ru>
	<35DAD65D.34165A2F@insightdist.com>
	<35DAE850.93FC000C@alumni.caltech.edu>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

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

So, I now get through several of the startup queries, including the
large object cursor loop, then crash. But clearly things are
progressing; just need to figure out what is getting called next and
(I'll bet) find out what else needs to be stubbed...

                        - Tom