FreeTDS Development Group

[David Chang <dchang AT fsautomation.com>]

Benjamin,

I think the easiest solution is an insert trigger on the tables that 
this black-box application writes to.  If the records are fairly small 
(less than 4000 Unicode chars), you could use xp_cmdshell to write the 
record to a text file.

http://www.databasejournal.com/features/mssql/article.php/1467601/A-general-logging-t-sql-process-to-write-to-txt-files.htm

There's some set-up to allow SQL Server to use xp_cmdshell, but it's not 
that difficult.

After the data is written out, you can delete the row(s) in the trigger.

DC

On 10/20/2016 2:06 PM, Frediano Ziglio wrote:
> 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
> _______________________________________________
> FreeTDS mailing list
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds