When the Database is set to SQL_SERVER, HibernateJpaVendorAdapter#determineDatabaseDialectClass sets the dialect to org.hibernate.dialect.SQLServerDialect. However there are multiple flavours of that dialect:
Microsoft SQL Server 2000 org.hibernate.dialect.SQLServerDialect
Microsoft SQL Server 2005 org.hibernate.dialect.SQLServer2005Dialect
Microsoft SQL Server 2008 org.hibernate.dialect.SQLServer2008Dialect
Ironically enough, if we don't see the dialect, Hibernate manages to detect the right one (in this particular case at least).
Should we consider stopping providing a dialect for SQL Server since we can't know which database is in use?
We generally intend to set the latest dialect for each particular database there, and we updated them for 5.0 already as part of #19116 / #18400. We can consider updating the dialect choices for 4.3.7 as well, depending on availability in the particular Hibernate version that we run against (since we're still supporting Hibernate 3.6+ there).
That said, since almost all databases have several dialects in place, the mechanism is arguably somewhat flawed in general. Could Boot simply not set the Database to begin with, leaving it entirely up to Hibernate?
I see two candidates worth updating in 4.3.x: SQLServer2008Dialect and MySQL5Dialect, with their predecessors horribly outdated in the meantime, and with both available in Hibernate 3.6.10 already.
Since it's easy enough to do a custom override to older versions there, I see no need to be super-conversative here. Also, most classic Spring Framework applications probably set their own specific dialect anyway (i.e. don't use our JPA Database enum to begin with), in particular when talking to a specific outdated enterprise database...