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

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 <[email protected]>:
>> 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
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds