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

Igor Korot <[email protected]> Fri, 21 Oct 2016 22:47:13 -0400
Newsgroups gmane.comp.db.tds.freetds
Message-ID <CA+FnnTzWK8aBaR8WLhD0io1JN=-ti+7WGdSCLiOBpA_NGtZ1pA@mail.gmail.com>
Hi,
If you can select the DB and and not connected only to MS SQL can I
suggest SQLite?

Thank you.


On Thu, Oct 20, 2016 at 7:18 PM, James K. Lowden
<[email protected]> wrote:
> On Thu, 20 Oct 2016 12:40:49 -0400
> Benjamin Moody <[email protected]> wrote:
>
>> 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.
>
>> Is it feasible to emulate the behavior of MS SQL Server
>
> Probably not.
>
>> * 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.
>
> I have long thought that TDS is a very respectable protocol, and with
> the right API (and implementation) would be convenient and efficient
> peer-to-peer data exchange.  BCP is particularly lean.  It benefits from
> its relational origins: everything is a table, and all datatypes are
> strictly defined (with a blob escape valve).  Sybase thought so, too;
> compared with their db-lib first draft, ct-lib is much more
> peer-oriented.
>
> While libtds could be repurposed to support a server implemementation,
> that was never its intended use.  It would be better to begin with a
> state machine, and static definitions of all the varieties of packets
> supported by different flavors of the protocol.  Client and server
> become co-processes exchanging data as TDS pages.
>
> A generic table-exchange service would be a boon to the industry.
> All popular data exchange protocols -- ftp, http, also protocol buffers
> & similar -- are based on files or bytestreams.  None are based on the
> TDS model: metadata once, rows follow, all bindings at runtime.
> What a shame the problem isn't more broadly understood, and addressed.
>
> --jkl
>
>
>
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds