Skip to Content.
Sympa Menu

freetds - Re: [freetds] Using freetds in Windows

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Using freetds in Windows
  • Date: Sat, 9 Jan 2010 13:55:35 -0500

James K. Lowden wrote:
> It's not
> a complete answer because (among other reasons) the db-lib error handler
> won't get the correct error string.

Hi Freddy,

A question for you on this topic.

tdserror() assumes errnum can be converted to a string with strerror(3).
On Windows that's not true; for winsock errors strerror(3) returns
"Unknown error". Somehow, we need to pass the Win32 error string
(returned from tds_prwsaerror()) to the client libraries. But how?

The db-lib call stack is:

connect(2) (e.g.)
tdserror(TDSCONTEXT, TDSSOCKET, msgno, oserr)
_dblib_handle_err_message(TDSCONTEXT, TDSSOCKET, TDSMESSAGE)
dbperror (DBPROCESS, msgno, oserr)

I don't want to change the interface to dbperror() or tdserror() just for
Win32.

My suggestion: add

char * winsock_errstr

to TDSSOCKET. Normally it's NULL. If libtds detects a win32 socket
error, it looks up the const static string with tds_prwsaerror() and
stores the pointer in winsock_errstr. When dbperror() calls the client
handler, it examines that pointer. If not NULL, it passes it to the
client handler instead of calling strerror(3). To avoid confusion,
dbperror() sets the pointer to NULL after the handler returns.

I think this would work with the other client libraries, too. What do you
think?

BTW, I'm working on updates to the UG for 0.92.

Regards,

--jkl






Archive powered by MHonArc 2.6.24.

Top of Page