TDS Remoting: A Better Way to Create Linked Servers for ODBC Sources

  • Comments posted to this topic are about the item TDS Remoting: A Better Way to Create Linked Servers for ODBC Sources

  • Thanks for the article but I am curious:

    When I need to retrieve data from a remote server using a Linked Server, I normally only use the Linked Server to start a parameterised stored procedure.  In that way I prevent the OPENQUERY from having to retrieve the contents for all tables being referenced via ODBC:

    In this way the target server is doing all the work and only the result set is returned.

    Does this product improve on this scenario?

  • The link under "create a linked server using TDS remoting" to the CDATA page returns a 404.
    I assume it should be linking to

  • The link in the final paragraph (Using TDS Remoting with CData SQL Broker) is broken - can you update it please?

  • I have some issues regarding speed and a ODBC conection to an Progress database.
    I can't read anywhere that this solution is also availible for an Progress database.

    Can anybody confirm that?

  • Disappointing that this article fails to define TDS or what is meant by "remoting" in this context and then provides a defective link to a vendor website. Based on my brief trial of a couple of CDATA products to connect to MS Dynamics 365 data, they seem useful. But I still don't know what TDS is. I presume you are referring to Tabular Data Stream protocol. Is this an ad for CDATA SQL Broker or a feature of SQL Server?

  • The title drew me in "A Better Way to Create Linked Servers", but it is misleading; it is all clearly an advertisement for a product to replace a native feature of SQL Server (a product which adds cost, complexity, additional dependencies, more breaking points, greater maintenance requirements, etc., etc.), I don't consider that "Better"... Not saying their product isn't good, but in the context of this advertisement it merely shows who it can sidestep proper developer education on how to write queries which ARE optimized for use with native SQL Server linked-server objects or ODBC methods; the strongest selling point of the advertisement was that simplistic-syntax queries perform poorly against a native linked-server object (which is true because such syntax is grossly suboptimal in such a case) and that their product instead allows such queries to perform better (which is cool I guess, but at what cost? and does that actually make your resulting applications "Better"?). Personally, I'd always (100% of the time) rather have my developers write correct code for each linked-server scenario and keep my environments simple (which alleviates countless other headaches down the road when migrating or maintaining environments), than introduce a new tool to dumb-down the development process so that I can use less-competent developers (which is what this product seems most suited for).

  • This article is clickbait.  Just an advertisement.   Misleading and self-serving.

  • I am going to dog-pile on current bandwagon but with a twist: when an article on SSC is suggesting to use a third party tool,they typically document that product with a copyright/trademark symbol along with the company name.  There is a native application called SQL Server Service Broker which I confused CData's product for. 

    For the author, I did reserve judgement until, I dug all the way through CData's web site to see if the tool was free as well as seeing if it just wrapped the Service Broker's functionality in itself (I could not determine this).

    Just my 2 cents...

Viewing 9 posts - 1 through 8 (of 8 total)

You must be logged in to reply to this topic. Login to reply