Syntra SQL Type Reference

When you introspect Syntra ODBC’s schema from a SQL client, each column is described by a type code and a type name. The Query Explorer’s Copy Schema JSON button surfaces these directly. Other clients expose them through their own metadata APIs (for example, pyodbc’s cursor.description, SQLAlchemy’s reflected columns, JDBC’s ResultSetMetaData).

This page is the authoritative chart of the Syntra SQL type codes observed in real schema output.

Chart

Code	Type name	Storage	Range / Precision	Example	Notes
16	`bool`	1 byte	`true`, `false`, or `NULL`	`true`	Boolean. Some clients serialize as `"true"` / `"false"` strings.
23	`int4`	4 bytes	Signed 32-bit: −2,147,483,648 to 2,147,483,647	`42`	Standard integer. Used for counts, flags, `sublevel`, etc.
1043	`varchar`	Variable	UTF-8, bounded by Syntra column `max_length` (up to 4095 for long memos)	`'Bank of America'`	Variable-length string. The default type for names, IDs, descriptions, memos.
1082	`date`	4 bytes	4713 BC to 5874897 AD	`'2026-06-15'`	Calendar date, no time component. Used for `txn_date`, `job_start_date`, `due_date`, etc.
1114	`timestamp`	8 bytes	4713 BC to 294276 AD, microsecond resolution	`'2026-04-08 14:30:00'`	Date and time without time zone. Used for `time_created`, `time_modified`.
1700	`numeric`	Variable	Arbitrary precision with declared scale (typically `(12, 2)` for money, `(12, 5)` for quantities)	`123456.78`	Exact decimal. Always use `numeric` for money to avoid floating-point rounding.

Reading Copy Schema JSON

When you click Copy Schema JSON in the Query Explorer, you get output like this for a table (here, accounts):

[
  { "name": "list_id", "type": "varchar", "oid": 1043 },
  { "name": "time_created", "type": "timestamp", "oid": 1114 },
  { "name": "is_active", "type": "bool", "oid": 16 },
  { "name": "sublevel", "type": "int4", "oid": 23 },
  { "name": "balance", "type": "numeric", "oid": 1700 },
  { "name": "account_number", "type": "varchar", "oid": 1043 }
]

The name is the column name you use in SQL. The type and oid both describe the same data type; use whichever is more convenient for your code generator or ORM.

Reading metadata from client drivers

pyodbc

pyodbc exposes the type per column via cursor.description. Each entry is (name, type_code, display_size, internal_size, precision, scale, nullable).

import pyodbc

conn = pyodbc.connect(
    "DRIVER={Syntra ODBC - QuickBooks ODBC};"
    "SERVER=127.0.0.1;PORT=5433;DATABASE=quickbooks;UID=qbconnect;PWD=yourpassword;"
)
cur = conn.cursor()
cur.execute("SELECT list_id, is_active, balance, time_created FROM accounts LIMIT 1")

for col in cur.description:
    print(col.name, "->", col.type_code, "precision", col.precision, "scale", col.scale)

The type_code pyodbc returns is the Python target type (str, int, bool, Decimal, datetime.date, datetime.datetime), not the numeric Syntra type code above. Use the chart to map between the two.

SQLAlchemy (pg8000 dialect)

SQLAlchemy reflects the schema using its own type objects. The String, Integer, Numeric, Date, DateTime, and Boolean classes cover every code on this chart.

from sqlalchemy import create_engine, inspect

engine = create_engine("postgresql+pg8000://qbconnect:yourpassword@localhost:5433/quickbooks")
inspector = inspect(engine)

for col in inspector.get_columns("accounts"):
    print(col["name"], "->", col["type"])

JDBC / ODBC metadata

Any JDBC or ODBC client can read column metadata via the driver’s standard catalog calls (DatabaseMetaData.getColumns in JDBC, SQLColumns in ODBC). The numeric SQL type returned by those APIs is the ODBC/JDBC SQL type (e.g., SQL_VARCHAR = 12), not the Syntra type code on this chart. Use your client’s documentation to translate.

Why these specific codes

The codes on this chart are stable. Syntra emits only the types it needs to represent the QuickBooks data model:

QuickBooks has no integer type larger than 32 bits in the SDK, so int8 is not used.
Money and quantity fields are always numeric with a declared scale. Syntra never uses float4/float8 for currency.
Date-only fields (txn_date, due_date) use date. Timestamps that include the time of record creation use timestamp without time zone. Syntra does not emit timestamptz because QuickBooks timestamps are already in the company file’s local time.
Text fields use varchar. Syntra does not emit the unbounded text type; every column has a bound that matches the QuickBooks schema.

If future versions of Syntra add fields that need other PostgreSQL-compatible types (e.g., uuid, bytea, timestamptz), this page will be updated.