Skip to Content.
Sympa Menu

freetds - Re: [freetds] some ct_options / ct_diag questions

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: ocfs2 AT asset-control.com
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] some ct_options / ct_diag questions
  • Date: Mon, 15 Dec 2008 16:01:13 +0100

> The include/tds.h definition of TDS_OPTION looks to be wrong, however.
> I'm not sure where those values came from. The fix is straightforward
but
> a little tedious:
Yeah, and especially the options turning off the arithmic abort/exception
are odd,
considering the fact that CS_OPT_ARITHABORT/IGNORE are boolean options, so
they
are just not needed. Also, there is no CS_OPT_... equivalent for
TDS_OPT_TRUNCABORT
with Sybase. I suspect this was implemented for a SQL Server backend?
I suppose an overhaul of the option setting code in freetds in desirable
to bring it
in sync the latest and greatest at the backend. I was able to fix this
with your
helpful directions, but I don't believe it make much sense at this point
to commit
this fix into the main freetds code. Maybe if I (ever?) have some time
left I can
do this overhaul.

> Correct. It's not complicated add, though. See the code in
> src/dblib/dblib.c::dbsetlname(). Call tds_set_app().
For this I would need access to a TDSLOGIN *, which you don't seem to have
from
a CS_CONTEXT *. CS_CONNECTION does have a reference to it, and also to a
CS_CONFIG,
so that could tie them together, but this does not help me, because the
connection handle
has not been allocated yet at the point of the cs_config() call.
It is a bit of a moot point though, since the runtime configuration file
is not
supported anyway. For now it suffices to have this particular cs_config()
call
be a no-op, returning CS_SUCCEED.

> Looking at the code, that's supposed to work. It might be the victim of
> bitrot, because error handling has seen a lot of work since that
function
> was written.
You are right, looks like it partially works, but it only supports
CS_CLIENTMSG_TYPE
and CS_SERVERMSG_TYPE where we use SQLCA_TYPE, which is easier to use as
it
automatically 'blends' client and server messages.

> Even fixing ct_diag to set the SQLCA correctly will be easier to correct
> in ct-lib than in your application. Why? Because you'll either rip up
> your application to route centralized message handling into your main
> thread of control, or you'll do the same thing (more easily, say I) in
> ct-lib itself, where it's already being done, thereby preserving your
> application code and compatibility with Sybase's implementation.
It is not too bad, we only use ct_diag() in our driver, in 7 or places.
I changed the code to use message callbacks and that works fine.
The 'upsert' and 'indate' now just use an extra ct_res_info() on
CS_CMD_SUCCEED
to obtain information on the number of affected rows and set the
'record not found' condition. Seems to work too.
Anyway, thx for the help.

Tim





Archive powered by MHonArc 2.6.24.

Top of Page