FreeTDS Development Group

["Fu, Steve" <sfu AT bofasecurities.com>]

Thanks for your response.

If we can restructure FreeTDS codes as
1. Prefix all functions with tds_, e.g. tds_ct_connect() (as in
tdsdbopen), and compile a library, let's say, libtdscore.a
2. Create stub functions with names the same as Sybase and call the
implementation function, e.g. ct_connect to call tds_ct_connect, and
package these functions with libtdscore.a to libsybdb.a or libct.a....

In this case, DBD::Sybase will work as it will pick up all necessary
libraries, like libsybdb.a from FreeTDS library directory, ... For those
that need FreeTDS with Sybase to co-exist, one can use db* to access
Sybase and tds* to access MSSQL, as long as the FreeTDS library dir is
listed later than Sybase library dir in LD_LIBRARY_PATH.


Steve Fu

-----Original Message-----
From: freetds-bounces AT lists.ibiblio.org
[mailto:freetds-bounces AT lists.ibiblio.org] On Behalf Of James K. Lowden
Sent: Tuesday, November 06, 2007 6:16 PM
To: FreeTDS Development Group
Subject: Re: [freetds] Has anyone integrate Sybase Library with FreeTDS
library

Fu, Steve wrote:
> I need to access Sybase and MSSQL servers from the same C++ program 
> and I Prefer to use Syabse CT lib to access Sybase and FreeTDS lib to 
> access MSSQL serever.
>  
> I cannot link libdb.a from both Sybase and FreeTDS? Are there any 
> suggestions or pointers?

I don't see any easy way to do this, Steve.  It's not a problem unique
to you; there are people who'd like to use DBD::Sybase (a C ct-lib
module) with the same discriminate-by-server feature.  


The first problem, as you know, is that FreeTDS *intentionally* produces
symbols that match Sybase's.  The second problem is that the header
files, while similar, aren't interchangeable.  

The C approach would be to change all the symbols at the source. 
Something like:

        #if FREETDS_IS_FREETDS
        #define ct_connect ct_connect_via_freetds
        #endif

There are 90 functions that would need that treatment.  Then you could
obviously link to both libraries (because you'd have new symbols).  Your
application would then need a giant switch statement to choose the right
version at runtime.  

An admin approach is to build FreeTDS as is, and use dlopen(3) to load
only one library at a time.  But you could use only one library at a
time.
 

The C++ approach would be to put the FreeTDS functions in their own
namespace, converting them to C++ linkage at the same time.  Then you
could overload the functions in the primary namespace by, say,
redefining the connection handle type e.g.:

CS_RETCODE ct_connect(  TDS_CONNECTION * con, 
                        CS_CHAR * servername, 
                        CS_INT snamelen)
        {
                return freetds::ct_connect( con, 
                                        servername, 
                                        snamelen );
        }

As I said, no easy way.  But there are ways.  Maybe the best one is to
keep improving FreeTDS to the point that other implementations aren't
worth the bother.  

HTH.

--jkl
_______________________________________________
FreeTDS mailing list
FreeTDS AT lists.ibiblio.org
http://lists.ibiblio.org/mailman/listinfo/freetds

NOTICE TO RECIPIENTS: Any information contained in or attached to this 
message is intended solely for the use of the intended recipient(s). If you 
are not the intended recipient of this transmittal, you are hereby notified 
that you received this transmittal in error, and we request that you please 
delete and destroy all copies and attachments in your possession, notify the 
sender that you have received this communication in error, and note that any 
review or dissemination of, or the taking of any action in reliance on, this 
communication is expressly prohibited. 

Banc of America Securities LLC ("BAS") does not accept time-sensitive, 
action-oriented messages or transaction orders, including orders to purchase 
or sell securities, via e-mail.

Regular internet e-mail transmission cannot be guaranteed to be secure or 
error-free. Therefore, we do not represent that this information is complete 
or accurate, and it should not be relied upon as such. If you prefer to 
communicate with BAS using secure (i.e., encrypted) e-mail transmission, 
please notify the sender. Otherwise, you will be deemed to have consented to 
communicate with BAS via regular internet e-mail transmission. Please note 
that BAS reserves the right to intercept, monitor, and retain all e-mail 
messages (including secure e-mail messages) sent to or from its systems as 
permitted by applicable law.

IRS Circular 230 Disclosure:
Any statements contained herein as to tax matters were neither written nor 
intended by the sender or BAS to be used and cannot be used by any taxpayer 
for the purpose of avoiding tax penalties that may be imposed on such 
taxpayer. If any person uses or refers to any such tax statement in 
promoting, marketing or recommending a partnership or other entity, 
investment plan or arrangement to any taxpayer, then the statement expressed 
above is being delivered to support the promotion or marketing of the 
transaction or matter addressed, and the recipient should seek advice based 
on its particular circumstances from an independent tax advisor. 
BAS hereby notifies the recipient that pursuant to the requirements of the 
USA Patriot Act (Title III of Pub. L. 107-56 [signed into law October 26, 
2001]) (the "Act") and other applicable laws, rules and regulations, BAS may 
be required to obtain, verify and record information that identifies the 
recipient. Such information includes the name and address of the recipient 
and other information that will allow BAS to identify the recipient in 
accordance with the Act and such other laws, rules and regulations.