Re: Is it possible to use FreeTDS to implement a stub TDS server?

Thank you all for your helpful suggestions and questions.

[Frediano Ziglio]
>   there is a server directory which implements part of it.
> The better part is the login used and tested to implement the pooling
> server which is in a good state.

Sounds useful indeed.  I'll have to take a look at that.

> The question is perhaps why you want to do it. Wouldn't be better and
> more efficient to use a message queue system directly?

Probably.  However, we don't have any control over the client; it's
provided as-is without source and with limited documentation from the
developers.  That's what I meant by a black box.  The only knobs we
can tweak are the IP address and login credentials for the server
where it will output data.

That said, at this point I am simply trying to understand the scope of
the problem and investigate possible ways we might go about
integrating this program into our systems.


[David Chang]
> I think the easiest solution is an insert trigger on the tables that
> this black-box application writes to.

That's a good suggestion and may be what we end up doing.


[James K. Lowden]
>> Let's say that I have a black-box application which produces a
>> massive, continuous stream of data and dumps it into an MS SQL Server
>> database.  I want to pull the data *out* of this database as quickly
>> as it is inserted, and pass it on for further processing in
>> near-real-time.
>
> By "black-box", I take it you mean the application cannot be changed,
> and its current implementation writes to MS SQL Server.

Right.

>> Is it feasible to emulate the behavior of MS SQL Server
>
> Probably not.

:) Fair enough.

>> * Does FreeTDS include low-level protocol code that would be useful in
>>   implementing such a stub server, or would it be simpler to start
>>   from scratch?
>
> Yes, and yes.
>
> The FreeTDS server code holds the rudiments of a beginning.  As far as
> I know, it has never been used for anything serious.  It doesn't
> implement any of the ACID features, nor does it recognize SQL.

My hunch is that for this application, we wouldn't need anything like
a real SQL parser, and that we would just need to enumerate the fairly
small set of SQL statements (and/or BCP transfers) that the program
will use, and supply canned responses.  But that remains to be seen.

Benjamin