FreeTDS Development Group

[Frediano Ziglio <freddy77 AT gmail.com>]

2016-10-20 17:40 GMT+01:00 Benjamin Moody <benjamin.moody AT gmail.com>:
> 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.
>
> In fact, I have no interest in keeping the data in a relational
> database at all; once it's been extracted I have no further use for
> the SQL database, and I don't have disk space to store the data
> permanently.  The SQL server is simply acting as a (rather
> inefficient) message queue.
>
> So what I would really like would be to avoid the use of MS SQL Server
> entirely, and simply connect the application to a "stub" server.  That
> server would pretend to be MS SQL Server, and would respond to the
> application's requests as a real SQL server would, but in fact would
> simply be relaying the inserted data to an AMQP server or similar.
>
> * Has anybody done anything like this before?
>
> * Is it feasible to emulate the behavior of MS SQL Server to the
>   degree that a client won't know the difference, assuming that the
>   client is treating the server as a write-only output repository?
>
> * 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?
>
> Benjamin


Hi,
  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.
The question is perhaps why you want to do it. Wouldn't be better and
more efficient to use a message queue system directly? If you can
change the queries of your client I could suggest (if changing
completely the client is not possible) an extended store procedure or
something similar (code that run on server but you can avoid data
writing).

Frediano