Innerhalb der SQL-Anweisungen müssen die Datenbankdatentypen angegeben werden (z.B. bei einer CREATE-TABLE-Anweisung). Die Abbildung von ODBC-Datentypen auf Datenbankdatentypen erfolgt aber nicht automatisch durch den ODBC-Treibermanager, sondern mit der Funktion Map(conn, type, mapType). Wenn die Umsetzung mit Map gelungen ist, erhält man mit GetTypeName den Namen und die Parameter des Typs als Zeichenkette. Es gibt je nach Datenbank nicht nur Unterschiede in der Menge der Datenbankdatentypen, sondern auch Unterschiede in den Parametern bei der Datendefinition. Der Datenbankdatentyp für eine Zeichenkette ist unter Oracle z.B. CHAR(32), unter MS Access aber bloß TEXT ohne weitere Parameter.
Auch bei Abfragen von Daten aus der Datenbank muß man wieder unterschiedliche Datentypen beachten. Die Datenfelder werden automatisch anhand der Datenbankdatentypen angelegt und können sich in ihren Typen von den beim Einfügen von Daten verwendeten Feldern unterscheiden (siehe Abbildung 
und Abbildung ). Wenn man z.B. einen ganzzahligen Wert ( LONGINT) in eine Oracle Datenbank einfügt, muß man als Datenbankdatentyp NUMBER verwenden. LONGINT wird dabei auf den ODBC-Datentyp SQLInteger abgebildet, der wiederum auf den Datenbankdatentyp NUMBER. Beim Auslesen der Daten wird der Datenbankdatentyp NUMBER allerdings auf den ODBC-Datentyp SQLChar beziehungsweise ARRAY OF CHAR abgebildet, weil es im allgemeinen nicht möglich ist, den Datenbankdatentyp NUMBER (Fixpunktzahl) mit den normalen numerischen Datentypen einer Programmiersprache darzustellen.
Die Umsetzung von Oberon-Datentypen auf Datenbankdatentypen (und vice versa) ist also im allgemeinen nicht ohne Informationsverlust möglich (siehe Abbildung ). Die Typen der Felder zur Datenkommunikation können sich also beim Einfügen von Daten und beim Auslesen unterscheiden (vgl. LongIntValueOf in AppendToBench1 im Beispielprogramm ODBCBench im Anhang ).
Figure: Umsetzung von Oberon- auf Datenbankdatentypen
Figure: Informationsverlust bei Umsetzung von Datentypen