FreeTDS Development Group

[Brian Bruns <camber AT ais.org>]

Hi Antonio,

Something of this sort was part of the original plan for FreeTDS but has
been since scrapped for lack of time/interest.  see
http://www.freetds.org/gateway.html for its historical value.  

On a more practical note, the libtdssrv library contains code to send many
types of TDS server packets to a client.  It works only with TDS 5.0
presently although it needs some work to become useful enough to pull this
off. It's probably 80% there.

The second thing to look at is in the "pool" directory.  It is a TDS
connection pooling server which does essentially what you are talking
about only it acts as a pass through for the remote TDS-based
server.  Basically, this would handle tracking connections, and forging
TDS authentication streams.

Here's what I would do.

1) take the src/server/unitest.c program.
2) make it fork a new process when connected to.
3) the forked process attempts to use the TDSLOGIN structure attributes to
connect to the Postgresql server.  Forge a ack/nak as required based on
this. 
4) wait for a SQL query (not in server lib...you'll need to write
it). Convert the SQL to T-SQL (MS/Sybase flavor).  Along these lines,
check my MDB Tools project for a decent (although unfinished) SQL
parser. some of the lighter weight databases may fall short on required
features such as outer joins and stored procs. (may be delayed until after
all other stuff is working, as long as the SQL sent is valid under both
servers).
5) Build results structure based on info returned from Postgresql and call
tds_send_result() for 5.0, you'll need to make functions for COL_INFO and
COL_NAME tokens for 4.2, or TDS7_RESULT for 7.0 as they are absent.
6) build row buffer and call tds_send_row() for each row processed.  
tds_send_row probably needs some work too.
7) send a TDS_DONE_TOKEN to wrap up.

There are quite a few nuances to all this about the order to send stuff
in, but basically what is listed there will make the client happy for
single result set querys.

Now multiple result set querys are an entirely different matter but I
wouldn't worry about that just yet.

BTW, TDS Pool could allow someone trying to reduce the reliance on SQL
Server to buy fewer CALs for the server, a significant savings.  I've
tested it under extreme loads and it holds up well, the only problem is it
gets all it's configuration information from a header file and thus needs
to be recompiled for each database.  This will change in the 0.53 series.

Beware that the TDS Pool code is GPL and not LGPL if it matters to you
(libtdssrv is LGPL).  All the pooling code is mine, and I could LGPL if it
makes more sense structurally.

Cheers,

Brian

On Tue, 19 Jun 2001, Antonio Ognio wrote:

> Hi there, 
> 
> I'm joining the list to learn about TDS and FreeTDS and specially
> to explore the idea of a deamon listing and serving TDS but using 
> another database as a the real backend, e.g. PostgreSQL.
> 
> I'm starting to think of this as some sort of SQL Server emulator.
> I guess the tough part is developing the "server" part. This "emulator"
> might even be configurable to act as a client to different databases
> for the the real backend.
> 
> Does somebody has a project like this in mind? Has somoene seen or 
> heard something related to this idea?
> 
> I can code some C. Is all what I need inside the sources of FreeTDS?
> You think a server might be coded just looking in the sources of
> FreeTDS? What other considerations are needed?
> 
> Many people in commercial enviroments seem to have applications
> (usually with no access to source code) designed to work with
> SQL server. I work developing PHP apps and giving some basic
> linux consultancy so many people talk about this to me. 
> 
> If this people could replace their NT/Win2k boxes running SQL Server
> with Linux Boxes running MySQL or PostgreSQL (or even Oracle when 
> available) many would move to Linux even at the costs in performance
> this sort of solution would have. 
> 
> In developing countries like mine, IT managers are very price
> sensitive and many are willing to move to Linux. I believe a technology
> like this could attract many people.
> 
> Thanks a LOT for your time and guidance.
> 
> Antonio
> Lima, Peru
>