Skip to Content.
Sympa Menu

freetds - Re: [freetds] dbsetlversion + DBVERSION_100

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] dbsetlversion + DBVERSION_100
  • Date: Tue, 15 Nov 2011 21:47:00 -0500

On Thu, 10 Nov 2011 13:54:43 +0100
LacaK <lacak AT zoznam.sk> wrote:

> can you please add into dblib.c support for Sybase 10 and above in
> dbsetlversion()

I'm slightly reluctant to apply this patch. Let me just debate it with
you a moment. Tell me where I go wrong.

http://msdn.microsoft.com/en-us/library/aa937064(SQL.80).aspx

dbsetlversion() is defined for Microsoft db-lib. It supports 4.2
(maybe) and 7.0+.

http://manuals.sybase.com/onlinebooks/group-cnarc/cng1110e/dblib/@Generic__BookTextView/39614;pt=39614

dbsetversion() is defined by Sybase. It supports version 4.2 (maybe)
and 5.0.

Your patch lets someone use the Microsoft function to set the Sybase
version. It's OK; it will work. But it's also a little strange, and
could be the product of confusion. Will someone connecting to a Sybase
database expect Microsoft db-lib semantics? Will they expect
dbdatecrack() to return months 1-12 instead of 0-11? Will they expect
dbconvert() to handle decimal/numeric types? Will they expect INT_EXIT
not to exit?

The answer *might* be Yes. One might have an application written for
Microsoft's db-lib that is now connecting to a Sybase database. But
the reverse seems more likely, given market trends.

I'm inclined to do the opposite: to *exclude* the functions that only
Microsoft defined unless --with-msdblib was used.

My question to you, then, is, Why not use dbsetversion()?

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page