freetds AT lists.ibiblio.org
Subject: FreeTDS Development Group
List archive
- 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
-
[freetds] some ct_options / ct_diag questions,
ocfs2, 12/12/2008
-
Re: [freetds] some ct_options / ct_diag questions,
James K. Lowden, 12/13/2008
- Re: [freetds] some ct_options / ct_diag questions, James K. Lowden, 12/13/2008
-
Re: [freetds] some ct_options / ct_diag questions,
ocfs2, 12/15/2008
- Re: [freetds] some ct_options / ct_diag questions, James K. Lowden, 12/15/2008
-
Re: [freetds] some ct_options / ct_diag questions,
ocfs2, 12/17/2008
- Re: [freetds] some ct_options / ct_diag questions, James K. Lowden, 12/17/2008
-
Re: [freetds] some ct_options / ct_diag questions,
James K. Lowden, 12/13/2008
Archive powered by MHonArc 2.6.24.