I’m pleased to release the latest update for SQL 4 CDS today! For this update I’ve focused on common problems I’ve seen people encounter with their queries from my telemetry. These updates should either mean that more queries can be executed immediately, or the error message is more descriptive to help solve common errors.

SQL handling improvements

This release fixes a bug which caused an error when referring to an aliased column in an ORDER BY clause, so you can now correctly run:

SELECT   name,
         count(*) as count
FROM     account
         INNER JOIN
         ON parentcustomerid = account.accountid
GROUP BY name,
ORDER BY count

For queries that need to be filtered in memory by SQL 4 CDS as the WHERE clause could not be converted to FetchXML, this release also fixes bugs:

  • comparing two lookup values
  • queries that include additional parentheses
  • filter date/time values
FROM   account
WHERE  telephone1 = '+44' + telephone2
       AND (createdby = ownerid)
       AND createdon >= '2020-01-01'

When limiting the number of rows to return using the TOP clause, I’d often see errors when people enclose the number in brackets. This is now fixed so you can correctly run:

SELECT TOP (10) name
FROM   account

To get the number of records, I’d normally write COUNT(*) but I’d often see people using COUNT(1) instead. This would work, but would trigger SQL 4 CDS to calculate the count in memory instead of converting it to an aggregate FetchXML query. Now COUNT(*), COUNT(1) and even SUM(1) are all treated identically and will take advantage of more efficient execution whenever possible.

Date filters often include calculations involving GETDATE() to get the current date & time, so I’ve now added support for this and other similar functions. You can now filter records using queries such as:

FROM   account
WHERE  createdon < DATEADD(month, -1, GETDATE())

This can’t be converted directly to FetchXML (see my earlier post for more information on the dynamic date filtering options offered by FetchXML), so where possible SQL 4 CDS will calculate the filter value and pass this into the FetchXML as:

  <entity name="account">
    <attribute name="name" />
      <condition attribute="createdon" operator="lt" value="2020-07-28 21:46:23" />

Although most queries people run are SELECT, I personally use it almost as much for UPDATE, INSERT and DELETE as well. To make it simpler for some bulk update scenarios I’ve added support for the REPLACE function, so you can write:

UPDATE new_blogpost
SET    new_content = REPLACE(new_content, 'Dataflex Pro', 'CDS')

T-SQL endpoint improvements

I’ve been doing quite a bit of work recently investigating the preview TDS endpoint for executing SQL queries directly against CDS, and one common issue I keep hitting is a valid query like this will generate errors:

SELECT account.name,
FROM   account
       ON account.accountid = contact.parentcustomerid

If you use SQL 4 CDS to execute the query against the T-SQL endpoint (you can turn this option on in the Settings dialog), the query will be automatically rewritten behind the scenes as:

SELECT account.name,
FROM   account AS account
       contact AS contact
       ON account.accountid = contact.parentcustomerid

This release also improves the user experience when enabling or disabling the TDS endpoint from within the SQL 4 CDS Object Explorer pane.

Error handling improvements

When you update a polymorphic lookup field, e.g. the parentcustomerid field on a contact, or regardingobjectid on an activity, you need to specify the entity type of the related record as well as the ID. This is a common error I see when someone writes a query such as:

UPDATE contact
SET    parentcustomerid = 'FAA30FF7-EDB2-4053-9A3C-BDBCEF645FAA'
WHERE  contactid = 'AA4E2264-9375-4CFF-B160-1CEF86BB94C7'

This needs to be written instead as:

UPDATE contact
SET    parentcustomerid = CREATELOOKUP('account', 'FAA30FF7-EDB2-4053-9A3C-BDBCEF645FAA')
WHERE  contactid = 'AA4E2264-9375-4CFF-B160-1CEF86BB94C7'

and the error message will now direct you to this solution.

I also commonly see errors due to people using double quotes to enclose string literals instead of single quotes. By default, SQL treats double quotes to enclose identifiers such as table or column names. There is an option in the Settings dialog to change this (untick the “Quoted Identifiers” checkbox), but if you use this incorrectly the error message will now suggest that you use single quotes instead.

FetchXML to SQL Conversion

Inspired by Michael Ochs’ virtual entity provider for connecting to SQL databases, I’ve now updated the conversion from FetchXML to SQL and made it available as a separate package for you to reuse in your own tools!

You could already do this using the full SQL 4 CDS engine, but this stripped down version makes it easier to include this functionality in plugins.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.