Re: Compiling using Visual Studio 2003

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane
> Sent: 10 February 2005 12:06
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Compiling using Visual Studio 2003
>
> Off topic,  FYI, I couldn't get the command line nmake to work. I did
> try putting in extra search paths & stuff but gave up shortly
> thereafter
> and continued my fight with the IDE.

That's how I build it all the time. Did you run vcvars32.bat first? That
should be all that is needed.

> I asked years ago agout this. Google for "psqlodbc bde
> schema" and it's
> the first match. Basically when using a schema enabled postgres the
> table names are returned as 'public.tablename' instead of plain
> 'tablename'. This screws up the applications as it upsets all
> the data
> models for the forms. The application needs to work with both the
> paradox table version and postgres so I need a way of hiding the
> "public." returned to paradox. I've managed to do this by
> adding another
> compile option "HIDE_PUBLIC_SCHEMA" and modifying the PGAPI_TABLES
> routine to return NULL if the schema name happens to be
> PUBLIC (#ifdef
> around the line set_tuplefield_string(&row->tuple[1],
> GET_SCHEMA_NAME(table_owner));). This seems to work.

SQLTables does it as it should:

SQLTables:
                In:
StatementHandle = 0x003B16F8, CatalogName = SQL_NULL_HANDLE, NameLength1
= 0, SchemaName = SQL_NULL_HANDLE, NameLength2 = 0,

TableName = SQL_NULL_HANDLE, NameLength3 = 0, TableType =
SQL_NULL_HANDLE, NameLength4 = 0
                Return:    SQL_SUCCESS=0

Get Data All:
"TABLE_QUALIFIER", "TABLE_OWNER", "TABLE_NAME", "TABLE_TYPE", "REMARKS"
<Null>, "cms", "content", "TABLE", ""
<Null>, "information_schema", "applicable_roles", "VIEW", ""
<Null>, "information_schema", "check_constraints", "VIEW", ""
<Null>, "information_schema", "column_domain_usage", "VIEW", ""
...
...

The schema is in the TABLE_OWNER column (as it is on SQL Server
incidently). If Paradox is prepending it onto the tablename, then it
should be fixed (though I appreciate you probably can't do that :-) ).
Can you work around it in your Paradox code though?

Regards, Dave.