Skip to Content.
Sympa Menu

freetds - Re: [freetds] msdblib (Re: Troubles upgrading to freetds-0.82)

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "ZIGLIO, Frediano, VF-IT" <Frediano.Ziglio AT vodafone.com>
  • To: "Mikhail Teterin" <mi+kde AT aldan.algebra.com>
  • Cc: gnome AT freebsd.org, freetds AT lists.ibiblio.org, ale AT freebsd.org
  • Subject: Re: [freetds] msdblib (Re: Troubles upgrading to freetds-0.82)
  • Date: Fri, 27 Jun 2008 13:40:19 +0200

>
> = Mmmm... yes, try to use version 4.2 to detect protocol
> version, however
> = every time you'll have 2 connections instead of one
>
> Strange -- does not the server identify itself at the initial
> "handshake" or
> something? Nothing similar to SMTP's "HELO", for example?
>

no, initial handshake is quite different for different protocol versions...

> = Mmm.... I think you are confusing server with client
> needs... msdblib means
> = that client wants some msdblib thing, not that you are connecting to
> = mssql...
>
> Yes, I may well be confusing things. My information comes from simply
> searching through the freetds code looking for what exactly
> is affected by
> specifying the --enable-msdblib configure-flag.
>
> The only thing I found is the default value of msdblib-field
> a DBPROCESS
> struct (tds_dblib_dbprocess).
>
> It appears to me, that in order for a freetds-build
> configured with the
> msdblib-flag to be usable against a Sybase server the
> application needs to
> change the connection's setting explicitly at run-time.
>

As stated msdblib don't specify to which vendor db you can connect but what
client
application wants...

> What I'd like to be possible is for the same application (or
> a higher-level
> toolkit such as Sybtcl) using the same FreeTDS-library to be
> usable against
> servers of different types... In addition to automatically
> figuring out the
> actual server's type, the fields of dbdaterec need to be aliased...
>
> For example, where I work, I have to connect to a SQL Server
> for some data and
> to a Sybase for other. I'd rather implement that in TCL, but
> I can't mix
> server-types in Sybtcl due to this problem and so am forced
> to use Java...
>
> Bottom line: I'd like the "--enable-msdblib" to turn from a
> build-time to a
> run-time (per connection) option. Preferably --
> autoinitialized based on the
> type of the server as detected during establishment of each
> connection.
>

no, no and no :)
An application should stake to a single library behavior, either ms or
sybase. There are
slightly difference but is up to application to provide a single behavior to
the
application.

> There are plenty of heterogenious environments and having to
> decide (per
> computer), whether to enable only Sybase or only MS SQL
> connectivity at
> build-time is too restricting...
>

The only things that change using --enable-msdblib or not is a single header,
binary
libraries are not affected. Defining MSDBLIB or SYBDBLIB before including
sqldb.h in
application decide which implementation do you want. This seems quite strange
but for
historical reasons we use --enable-msdblib. Formerly the ABI was a bit
different using and
not using this flag. I personally recommend that every application that
intend to use
FreeTDS define MSDBLIB or SYBDBLIB so to avoid strange behavior. If Sybctl
use msdblib
just define MSDBLIB. Nothing to recompile or change in FreeTDS!

freddy77

Attachment: smime.p7s
Description: S/MIME cryptographic signature




Archive powered by MHonArc 2.6.24.

Top of Page