Any! Simply. As long as they really are ODBC databases. But let us first define ODBC. We quote the Webopedia:

ODBC = Short for Open DataBase Connectivity, a standard database access method developed by the SQL Access group in 1992. The goal of ODBC is to make it possible to access any data from any application, regardless of which database management system (DBMS) is handling the data. ODBC manages this by inserting a middle layer, called a database driver, between an application and the DBMS. The purpose of this layer is to translate the application's data queries into commands that the DBMS understands. For this to work, both the application and the DBMS must be ODBC-compliant -- that is, the application must be capable of issuing ODBC commands and the DBMS must be capable of responding to them. Since version 2.0, the standard supports SAG SQL.

That means that no matter how data and metadata (indexes) are stored by the actual DBMS and how it works internally ODBC defines a standard command set to manipulate the database.

However, one thing is theory - another one is practice! When we were developing the SQLyog Import External Data Tool we came across quite a few non-standard issues with practically every ODBC database. Not only 'obscure' ones but also the most commonly used ones whether they were database server systems or personal/office-suite type databases. Non-standard implementation of commands, datatypes, hidden temporary tables etc. And we found even more issues with the ODBC-drivers. We had expected some of that - but not that much.

We can say that all issues with all sort of 'standard' databases are sorted out. The Import External Data Tool knows how to handle these issues - it uses a subset of the command set that works a standard way with the individual database type, or it has - when it has been necessary - implemented fully functional 'workarounds' for the issues.

However there are still in existence a lot of database systems in use that were created in the first decade of the 'PC-era' - say from 1985 to 1995 - that were not originally created to be ODBC-compliant, but have become so at a later stage of their development. Those databases are mostly used with proprietary administrative systems. Sometimes you will have to purchase an ODBC-add-on-module for ODBC-compliance. And if it really is ODBC-compliant it will work with SQLyog too! But we can't know all those systems. Some have not been marketed for a decade; some have a very local existence.