TDS endpoint availability is, probably, one of the coolest technical capabilities introduced by Microsoft in the last few months. However, even though it’s great to be able to run SQL queries in the SQL management studio as described in Microsoft docs:
There are other usage scenarios which seem to be very enticing.
Using it for data reporting would be one option:
There are at least a couple of others, though.
1. We can use TDS endpoint when developing custom applications that need access to CDS
For example, I have updated my angular portal template to utilize TDS endpoint when reading cases/notes from CDS. How difficult was it? It was not, at all:
Sure this change meant a bit of code refactoring; however, converting from the entity-base syntax to the sql data reader syntax is very straightforward.
What are the benefits?
- Well, SQL has always been easier for me to understand than FetchXML or QueryExpressions
- In terms of specifying query conditions, SQL is definitely more advanced
- Finally, and I’m not sure it will stay this way(but, on the other hand, I am not sure if it’s technically possible to change this), I have a feeling TDS connection will bypass API limits
Of course the last item on the list above is only applicable to the “read” requests, since TDS endpoint only provides read access at this time. But, come to think of it, “read” operation is what the portal will be doing most of the times. The remaining (“Create”/“Update”/”Delete”) ones will still be done through the SDK.
If you are wondering about the connection string for the SqlConnection, here is how it looks like:
Server=<orgname>.crm3.dynamics.com,5558;Authentication=Active Directory Password;Database=<orgname>.com;User Id=<user name(email address)>;Password=<password>;
2. Data migrations with SSIS
- Do you want to use a tool, such as SSIS, to extract data from CDS? Of course KingswaySoft connector has become a de-facto standard for CDS integrations through SSIS, but TDS endpoint availability opens up some nice opportunities.
You just need to create an ADO connection:
And use ado data source after that:
Just keep in mind that TDS endpoint seems to be having troubles getting the metadata that way, so I had to specify the database name manually, and, also, had to use a SQL command option since none of the table names were visible. Maybe I just missed a setting somewhere, but, even so, it’s a already working as you can see in the “preview” window on the screenshot above.
As far as metadata goes, and that’s just a note so we don’t get too carried away, there are definitely some limitations. For example, my attempt to generate a “create” script for the account table failed miserably:
Not that I need it too much, just wanted to quickly create a table in my local database for the SSIS script above