Skip to Content.
Sympa Menu

freetds - RE: [freetds] ct-options

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "Thompson, Bill D (London)" <bill_d_thompson AT ml.com>
  • To: "FreeTDS Development Group" <freetds AT lists.ibiblio.org>
  • Subject: RE: [freetds] ct-options
  • Date: Thu, 14 Apr 2005 11:11:58 +0100

James,

The ct_options() implementation in Sybase is much more messy than I
imagined.

It turns out that there is a TDS 5.0 message which corresponds to the
ct_options() call.
This allows you to SET/GET/CLEAR(return to default) the various
settings.
It seems to me that the settings that are manipulated by ct_options()
are maintained on the server side, rather than on the client side of
ct-library.

It would also appear to be the case that these settings are NOT kept in
line with actual active server settings.

So, when you GET a setting using ct_options straight after connecting,
before SETting any, they appear to be undefined.
I tried this with the DATEFIRST setting. This should always have a value
(between 1 and 7).
However ct_options returned zero as the value for this option, if I got
it straight after connecting.
>From this I deduce that you can only do a ct_options GET after a
ct_options SET, if you hope to get a valid value.

I tried using ct_options with the CLEAR options, which is supposed to
set the value to its default.
This option appears to be unimplemented (at least in my version of
Sybase) and returned a server error message and client library error.

I'll carry on investigating, but I'm tempted to just implement the
option that we require for DBD::Sybase,
which I would implement issuing SET CHAINED/IMPLICIT_TRANSACTIONS
commands.

Bill

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of Lowden, James K
Sent: 12 April 2005 17:30
To: ml AT freetds.org
Subject: [freetds] ct-options


> From: Thompson, Bill D (London)
> Sent: Tuesday, April 12, 2005 8:36 AM
>
> I'll have a go at ct_options().
> I had started to look at it anyway.

Sounds good, Bill.

> I reckon that the ctlibrary ct_options(CS_OPT_CHAINXACTS),
> and its partner "SET" option "SET CHAINED..",
> are the same as SQL server's "SET IMPLICIT_TRANSACTIONS ON"
> command. They seem to be the same thing as far as I can tell.

I think so; that's what I had in mind. I haven't traced a ct-lib
conversation with tcpdump.

We're going to need a whole new structure, to support the GET option.
The information is not always (conveniently) available from the server,
and the Open Client Client-Library/C Reference Manual indicates the
settings are maintained by the library:

"
A Client-Library application sets and clears Adaptive Server
query-processing
options in one of two ways:

* By using a Transact-SQL language command (set)
* By calling ct_options

An application may use only one of these methods; otherwise, Client-
Library/server communications may become confused.

The ct_options method is recommended because it allows an application to
check the status of an option, which is not allowed by the Transact-SQL
set
command.
"

I don't see how "communications may become confused"; I don't see any
reason for ct-lib to refer to settings that were transmitted to the
server. But I can easily see that an application (or application
programmer) might become confused, if it sent a language command and
then attempted to ascertain the new status with ct_options().

It looks to me like Sybase wanted to provide the appearance of being
able to interrogate the server's status, but supplied responses from a
local one-way cache. Maintaining 1 datum in 2 places is always a can of
worms....

--jkl


-----------------------------------------
The information contained in this transmission may contain privileged
and
confidential information and is intended only for the use of the
person(s) named
above. If you are not the intended recipient, or an employee or agent
responsible
for delivering this message to the intended recipient, any review,
dissemination,
distribution or duplication of this communication is strictly
prohibited. If you are
not the intended recipient, please contact the sender immediately by
reply e-mail
and destroy all copies of the original message. Please note that we do
not accept
account orders and/or instructions by e-mail, and therefore will not be
responsible
for carrying out such orders and/or instructions. If you, as the
intended recipient
of this message, the purpose of which is to inform and update our
clients, prospects
and consultants of developments relating to our services and products,
would not
like to receive further e-mail correspondence from the sender, please
"reply" to the
sender indicating your wishes. In the U.S.: 1345 Avenue of the
Americas, New York,
NY 10105.
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds
--------------------------------------------------------

If you are not an intended recipient of this e-mail, please notify the
sender, delete it and do not read, act upon, print, disclose, copy, retain or
redistribute it. Click here for important additional terms relating to this
e-mail. http://www.ml.com/email_terms/
--------------------------------------------------------




Archive powered by MHonArc 2.6.24.

Top of Page