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: Igor Korot <ikorot01 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: Fri, 21 Oct 2016 22:47:13 -0400

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
<james.k.lowden AT icloud.com> wrote:
> On Thu, 20 Oct 2016 12:40:49 -0400
> Benjamin Moody <benjamin.moody AT gmail.com> 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
> FreeTDS AT lists.ibiblio.org
> http://lists.ibiblio.org/mailman/listinfo/freetds




Archive powered by MHonArc 2.6.24.

Top of Page