The silly thing of having out-of-date interface files + up-to-date SDK files is that nothing matches and that (generally) the next step is to ‘duke it out’ with everything, except for the compiler. Here’s what I was fighting out:
Using generic ODBC calls (ADO, actually) you can basically filter out the provider’s database types: in this case, I’m after specific Postgres datatypes, but the concept should be the same for any database/ODBC source. The API says the following:
Providertypes:
recordset = connection.OpenSchema (QueryType, Criteria, SchemaID);
where QueryType = adsProviderTypes,
QueryType = DATA_TYPE/BEST_MATCH (not applicable for Postgres)
SchemaType = empty
To find a field’s datatype, you issue the same method with querytype of adsSchemaColumns and pass on the tablename as SchemaID. That particular dataset will return an ADO datatype for each field in a table (fieldname ‘DATA_TYPE’). Here’s where the confusing part comes in: there’s only one ADO type defined for string fields, namely DBTYPE_WSTR (well, not completely true, if your database doesn’t support Unicode, but I’ll leave that out for now). How to distinguish, say char(xx) and varchar(xx) fields? Or even, memo/text types?
The easy part is to tell the difference between, memo and varchar(xx) fields: varchar fields will generally have a maximum size (in case of Postgres, 254 characters). Memo’s generally don’t. So, to tell the difference between the two, do a crossreference on ‘CHARACTER_OCTET_LENGTH’ (remember octets!) and ‘COLUMN_SIZE’. For the specific char vs. varchar issue, you apparently have to see if bit 16 (DBCOLUMNFLAGS_ISFIXEDLENGTH) is set in the adsSchemaColumns dataset’s ‘COLUMN_FLAGS’.
Yes. Really. I’m not kidding.