Since 4D v11 SQL, 4D includes a built-in SQL server (and of course support for SQL). This SQL server can be accessed externally by other 4D databases (see SQL LOGIN).

In the past you might have accessed external 4D databases via 4D Open or Web Services, or some third-party technology. The disadvantage with this approach is it requires two sets of code to do the same thing: DB4D code to access the internal database; and the other API to access external databases. Consider this example:

ext_SQL_Login Begin SQL     SELECT Data     FROM TheTable     WHERE uuid = :$UID_t     INTO :$theData_t; End SQL ext_SQL_Logout

The database that uses this code is a component. The matrix database contains no tables. The ext_SQL_Login method automatically detects if the code is executing as a component or not. If the code is executed in matrix mode, an external connection is made. If the code is executed as a component, no external connection is made, the internal database is queried instead:

` ext_SQL_Login method. If (Not(UTIL_IsComponent))     SQL LOGIN(...;...;...) End If

SQL eliminates the need to maintain two sets of code. If you take a SQL approach to data access you have one unified language that will work against any 4D database. Further to that if the databases share the same table/field names, or if you build a mapping system, the same exact code can be used to access the internal database and any external databases.

SQL data access also gives tremendous power to compartmentalized code (components) as well as compartmentalized data (external databases, new in 4D v12). Of course SQL can be leveraged to access other non-4D databases as well.

When compared to DB4D commands, SQL is not without it's limitations of course. There is no concept of Selections or Sets, for example. The idea here is not to completely replace DB4D code but, rather, use SQL where appropriate. Multiple-database access is one case where SQL excels.