As 4D's SQL implementation evolves, users are sometimes left to wonder why certain features might not be implemented. SQL compliance is, perhaps unfortunately, a complex issue.

SQL is not a "standard" in the typical sense of the word. Here are some of the common concerns:

• The complexity and size of the SQL standard means that most implementors do not support the entire standard.


• The standard does not specify database behavior in several important areas (e.g., indexes, file storage…), leaving implementations to decide how to behave.


• The SQL standard precisely specifies the syntax that a conforming database system must implement. However, the standard's specification of the semantics of language constructs is less well-defined, leading to ambiguity.

(from https://en.wikipedia.org/wiki/SQL#Criticism)

A common example of this disparity is "bug reports" requesting a vendor-specific implementation in 4D. Just because another vendor implements a certain behavior does not mean it is part of the SQL standard. These are not bugs, these are feature requests (and feature requests are totally valid, but they belong in the feature request forum, not the bug database).

For these reasons alone, if 4D were only a SQL DBMS the implementation would already be a daunting task. But remember 4D already includes its own database language (sometimes referred to as DB4D).

If a feature is added to SQL it must also be added to 4D and, therefore, we must make sure it does not break 4D. Note that this does not mean complete parity between the two languages; this is impossible. One example is 64-bit integer support: even though this type does not exist in the 4D language you can still use it. The SQL engine converts the data (truncating it to a 32-bit integer); this has direct impact to testing and certification throughout 4D, not just the SQL engine.

On overriding goal in 4D's SQL implementation is that the behavior be compliant with the SQL standard even if the exact syntax differs.