RE: bug in ODBC driver (and fix) - Mailing list pgsql-interfaces

Hello Mindaugas,

> Got it to compile correctly, however, it doesn't link correctly. It's
> gettin some unresolved external symbols... by the looks of which look
> like its targeted to the unix platform.

It's not targeted for the unix platform, all of these function calls are
Winsock.dll calls (Microsoft's BSD-ish sockets implementation).  I would
imagine the ODBC driver links to the dll at runtime (I seem to remember
that you need a definitions?? file to pull in Winsock calls at runtime).
If not you can link against the static library Wsock32.lib.

The ODBC driver uses TCP/IP socket calls to talk between your client and
the Postgres backend, thats why these calls are needed.

Hope this helps...

Paul M. Breen, Software Engineer - Computer Park Ltd.
Tel:   (01536) 417155
Email: pbreen@computerpark.co.uk

On Fri, 19 Jan 2001, Mindaugas Idzelis wrote:

> The ODBC driver I had problems with is found at:
> ftp://ftp.postgresql.org/pub/odbc/latest/postdrv.exe
>
> This is apparently revision v06-50-0000. I patched the sources to this
> particular version. I just realized that there is a copy of the odbc driver
> in the postgresql source tree. I'm going to try to compile that with visual
> c++ 6.0 now.
>
> <time warp>
>
> Got it to compile correctly, however, it doesn't link correctly. It's
> gettin some unresolved external symbols... by the looks of which look
> like its targeted to the unix platform.
>
> connection.obj : error LNK2001: unresolved external symbol _htonl@4
> socket.obj : error LNK2001: unresolved external symbol _htonl@4
> psqlodbc.obj : error LNK2001: unresolved external symbol _WSACleanup@0
> psqlodbc.obj : error LNK2001: unresolved external symbol _WSAStartup@8
> socket.obj : error LNK2001: unresolved external symbol _closesocket@4
> socket.obj : error LNK2001: unresolved external symbol _shutdown@8
> socket.obj : error LNK2001: unresolved external symbol _connect@12
> socket.obj : error LNK2001: unresolved external symbol _socket@12
> socket.obj : error LNK2001: unresolved external symbol _htons@4
> socket.obj : error LNK2001: unresolved external symbol _gethostbyname@4
> socket.obj : error LNK2001: unresolved external symbol _inet_addr@4
> socket.obj : error LNK2001: unresolved external symbol _ntohl@4
> socket.obj : error LNK2001: unresolved external symbol _ntohs@4
> socket.obj : error LNK2001: unresolved external symbol _send@16
> socket.obj : error LNK2001: unresolved external symbol _recv@16
> Debug/psqlodbc.dll : fatal error LNK1120: 14 unresolved externals
>
>
> The file version for the odbc driver taken from the 7.1beta3 source tarball
> says this is ODBC version v06-40-0009. I downloaded the equivalent
> precompiled windows version from
> ftp://ftp.postgresql.org/pub/odbc/versions/v06-40-0009/postsrc.zip but this
> version DOES NOT have the int4out fix. Basically, none of the precompiled
> windows versions have that fix. I patched the 6-50-0000 code to support
> 7.1beta3. If anyone on the list is interested, have them download and try
> out that one.
>
> There is apparently some fixes that aren't incrementing version numbers, and
> also some versions that have the same number for windows and unix, they are
> not the same source. Confusing!
>
> --min
>
>
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Friday, January 19, 2001 1:13 PM
> To: Mindaugas Idzelis
> Cc: pgsql-interfaces@postgresql.org
> Subject: Re: [INTERFACES] bug in ODBC driver (and fix)
>
>
> Mindaugas Idzelis <mai3116@ritvax.isc.rit.edu> writes:
> > If it was fixed in 7.0.3, it has not yet been fixed in 7.1beta3.
>
> Oh?  I'm quite sure there is no reference to int4out in ODBC now.
> Look for yourself if you don't believe me.  That patch was applied
> to the main branch back in August.
>
> Are you sure you are using a driver built from the current ODBC sources,
> and not 7.0.2 or earlier?
>
> > Also, what is wrong with the following sql query?
> > create unique index primary on tablename ( tableid );
>
> PRIMARY is an SQL reserved word.
>
>             regards, tom lane
>