Skip to Content.
Sympa Menu

freetds - RE: [freetds] ODBC unimplemented functions excluded?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Craig A. Berry" <craigberry AT mac.com>
  • To: freetds AT lists.ibiblio.org
  • Subject: RE: [freetds] ODBC unimplemented functions excluded?
  • Date: Fri, 31 Jan 2003 14:13:52 -0600

At 11:13 AM +0100 1/31/03, ZIGLIO Frediano wrote:
> > > Previous version provide stub for all missed function but
>> Driver Manager
>> > do a best works than our stubs (it can also emulate some
>> functions using
>> > some other) so is best to not provide stub.
>> >
> > > freddy77

and then Nick Gorham said:

> > If you just don't return that they are supported in a SQLGetFunctions
> > call, its as good as not exporting them to unixODBC.

and then Frediano replied:

>No, some Driver Manager check function presence using exported functions.

Thanks for the replies. If I understand this right, some driver
managers provide their own stubs, and some (like unixODBC) don't ever
call unimplemented functions because they know who's there and who's
not. Others assume if the function exists it's implemented.

My current dilemma arises when building the driver's dynamic library
(shareable image, as they're called) on VMS. I need to specify what
list of functions to export, and while there are various ways to
maintain such a list either manually or automatically, by far the
easiest (and in some ways best) thing to do would be to specify the
full API and let the stubs get linked into the shareable image.

Is there something a bit more configurable than "#if 0" that could be
done here so the stubs can be made optionally visible to the
compiler? I've learned my lesson and won't suggest a macro to
redefine "0" ;-).

--
________________________________________
Craig A. Berry
mailto:craigberry AT mac.com

"... getting out of a sonnet is much more
difficult than getting in."
Brad Leithauser




Archive powered by MHonArc 2.6.24.

Top of Page