Skip to Content.
Sympa Menu

freetds - Re: [freetds] Is it possible to use FreeTDS to implement a stub TDS server?

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Frediano Ziglio <freddy77 AT gmail.com>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] Is it possible to use FreeTDS to implement a stub TDS server?
  • Date: Thu, 20 Oct 2016 22:06:22 +0100

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




Archive powered by MHonArc 2.6.24.

Top of Page