Microsoft SQL Server and Event Calendar Module

I am developing my silverstripe page with Microsoft SQL Server and there are some problems with the event calendar module.

1. It uses '`' hardcoded as field and table qualifiers. SQL Server only accepts '"' or square brackets '[' and ']'. The base silverstripe framework uses '"', so I think there should be some constant for this...

2. The query for getrecurrengEvents has a Sort Order Defined: "`CalendarDateTime`.StartDate ASC"
SqL Server won't accept this. The table CalendarDateTime is joined in the query, but no field of it is in the group by clause, so SQL Server won't allow this sort order.

yes I have seen this in the module as I have search for '`' through the whole SilverStripe source code. By now I have just done a search and replace with '"'. I see that your solution works, but in my opinion this has to be done on Database Module level. I would create an abstract function QualifyIdentifier at the base DB module which would do the job. Each other module has to implement this function and do the proper qualifying. Although SQL Server will accept '"' as qualifiers but the preferred way should be using square brackets. This could be handled within such a function and you only have to do it once, not in every file.
Last point: This problem is throughout all Modules from UncleCheese ;-)

Regarding the second problem: As I don't need DateTimes but only Announcements it is ok that I just deleted the sort order.

you are right, we shouldn't have to bother. The whole problem is solved in 2.4: double quotes only, period. They are the only standard compliant enclosures for identifiers and work for all adapters (MySQL, SQLite, Postgres, SQL Server), no backticks, no brackets, they are proprietary.

The only reason for the proposed admittedly ugly DB::USE_ANSI_SQL approach is for legacy code where we can't fix it on the adapter level.

For me the idea of open source code is you get it for free and in return when you find a bug you fix it and give back, so everybody is benefitting. Save the next SQL Server dev from the same hassle you had and support UC ;-) That would be great.