Thread: Compiling using Visual Studio 2003
Hi there I'm trying to compile the psqlodbc driver using visual studio 2003. I'm not an expert at this program but have managed to get it to compile (& work) with tons of warnings. Does anyone know if (a) this is usual to get all these warnings on compiling in windows and (b) should I worry about any of them? My reasons for compiling are that I'm hoping to hack the driver a little to allow me to use Paradox to connect to a more recent version of Postgres. I'm currently limited to using 7.2.X as that was the last version that did not use schemas. I think with a little hacking I'll be able to hide the "information_schema" and also the "public." from the table names returned to Paradox through ODBC (indeed I've already figured out how to do this but am having another issue that I've not worked through yet). Thanks for any response Paul -- Paul Cochrane (paul.m.cochrane@tuht.scot.nhs.uk) +-------------------------------------------------------- | Tayside Orthopaedic & Rehabilitation Technology Centre | Ninewells Hospital & Medical School | Dundee, Scotland, UK. | DD1 9SY | Phone: Internal: 36284 | External: +44 (1382) 496284 | Fax: +44 (1382) 496322 +--------------------------------------------------------
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane > Sent: 10 February 2005 11:06 > To: pgsql-odbc@postgresql.org > Subject: [ODBC] Compiling using Visual Studio 2003 > > Hi there > > I'm trying to compile the psqlodbc driver using visual studio > 2003. I'm > not an expert at this program but have managed to get it to > compile (& > work) with tons of warnings. Does anyone know if (a) this is usual to > get all these warnings on compiling in windows and (b) should I worry > about any of them? You should get few, if any warnings. > My reasons for compiling are that I'm hoping to hack the > driver a little > to allow me to use Paradox to connect to a more recent version of > Postgres. I'm currently limited to using 7.2.X as that was the last > version that did not use schemas. I think with a little > hacking I'll be > able to hide the "information_schema" and also the "public." from the > table names returned to Paradox through ODBC (indeed I've already > figured out how to do this but am having another issue that I've not > worked through yet). Why are you limited to 7.2.x? The driver works just fine with all recent versions of PostgreSQL (bar the odd minor bug of course). Regards, Dave.
Hi Paul, >> I'm trying to compile the psqlodbc driver using visual studio 2003. >> I'm not an expert at this program but have managed to get it to >> compile (& work) with tons of warnings. Does anyone know if (a) this >> is usual to get all these warnings on compiling in windows and (b) >> should I worry about any of them? > > You should get few, if any warnings. Using the IDE you will get a lot of warning (at least I did). Do you also get them if you compile with the makefile? I fso, check the makefile and the corresponding options in the IDE. Groeten, Joost Kraaijeveld Askesis B.V. Molukkenstraat 14 6524NB Nijmegen tel: 024-3888063 / 06-51855277 fax: 024-3608416 e-mail: J.Kraaijeveld@Askesis.nl web: www.askesis.nl
Dave Page wrote: > > > > >>-----Original Message----- >>From: pgsql-odbc-owner@postgresql.org >>[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane >>Sent: 10 February 2005 11:06 >>To: pgsql-odbc@postgresql.org >>Subject: [ODBC] Compiling using Visual Studio 2003 >> >>Hi there >> >>I'm trying to compile the psqlodbc driver using visual studio >>2003. I'm >>not an expert at this program but have managed to get it to >>compile (& >>work) with tons of warnings. Does anyone know if (a) this is usual to >>get all these warnings on compiling in windows and (b) should I worry >>about any of them? >> >> > >You should get few, if any warnings. > > I'm getting 65!!. I've just figured out what was causing it. It was the option for Detect 64 bit Portability issues. I now get 0 warnings and feel much happier now :-) 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. >>My reasons for compiling are that I'm hoping to hack the >>driver a little >>to allow me to use Paradox to connect to a more recent version of >>Postgres. I'm currently limited to using 7.2.X as that was the last >>version that did not use schemas. I think with a little >>hacking I'll be >>able to hide the "information_schema" and also the "public." from the >>table names returned to Paradox through ODBC (indeed I've already >>figured out how to do this but am having another issue that I've not >>worked through yet). >> >> > >Why are you limited to 7.2.x? The driver works just fine with all recent >versions of PostgreSQL (bar the odd minor bug of course). > > > 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. My next problem which I'm working on at the moment is that the new driver completely crashes with no error messages when opening certain tables. I can open some but others simply crash paradox (no GPF no nothing). All I get is 2 errors in the server log: could not receive data from client: Connection reset by peer & unexpected EOF on client connection. I'm not expecting you to solve this one at present. It may be paradox being a bit flaky and nothing to do with the ODBC driver (although I suspect it is). All I know is that it works with psqlodbc 7.3.200 & postgres 7.2.X but isn't working with my compiled driver 8.0.4 and postgres 8.0.1. I'm about to downgrade postgres to 7 to see if that has any more luck. Thanks for getting back so quickly. -- Paul Cochrane (paul.m.cochrane@tuht.scot.nhs.uk) +-------------------------------------------------------- | Tayside Orthopaedic & Rehabilitation Technology Centre | Ninewells Hospital & Medical School | Dundee, Scotland, UK. | DD1 9SY | Phone: Internal: 36284 | External: +44 (1382) 496284 | Fax: +44 (1382) 496322 +--------------------------------------------------------
> -----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.
Dave Page wrote: >>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'm Thick. What is this file? It doesn't seem come with psqlodbc and there is no mention of it in the doc on the GBORG site about compiling the driver. I was changing to the extracted dir & trying nmake..... >>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). > I know that the driver is doing it as it supposed to. It's paradox/BDE that can't cope with the schema stuff. >If Paradox is prepending it onto the tablename, then it >should be fixed (though I appreciate you probably can't do that :-) ). > > I wish I could. Open source is a great invention. If its broken try and fix it yourself. >Can you work around it in your Paradox code though? > > I can fix it in code but this would break the compatibility of using either the paradox tables or postgres tables. I would have to have two different versions of each form etc & record many lines of code to say "If in postgres add a public. to every table name" which is a huge pest & I don't want to have two version of each form to try & keep in sync with each other. If I get it working, I may update the ODBC driver form to have a couple of tick boxes to make this an option in the driver and send you the changes made. -- Paul Cochrane (paul.m.cochrane@tuht.scot.nhs.uk) +-------------------------------------------------------- | Tayside Orthopaedic & Rehabilitation Technology Centre | Ninewells Hospital & Medical School | Dundee, Scotland, UK. | DD1 9SY | Phone: Internal: 36284 | External: +44 (1382) 496284 | Fax: +44 (1382) 496322 +--------------------------------------------------------
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane
> Sent: 10 February 2005 14:32
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] Compiling using Visual Studio 2003
>
> Dave Page wrote:
>
> >>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'm Thick. What is this file? It doesn't seem come with psqlodbc and
> there is no mention of it in the doc on the GBORG site about
> compiling
> the driver. I was changing to the extracted dir & trying nmake.....
It sets up the DOS environment for VC and is part of Visual Studio. On
my system I have it in:
C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin (VS.NET 2K3)
And
C:\Program Files\Microsoft Visual Studio\VC98\Bin (VS6)
Note that if you can it's better to use VC++6 as the required runtimes
are generally already on most machines.
> I can fix it in code but this would break the compatibility of using
> either the paradox tables or postgres tables. I would have to
> have two
> different versions of each form etc & record many lines of
> code to say
> "If in postgres add a public. to every table name" which is a
> huge pest
> & I don't want to have two version of each form to try & keep in sync
> with each other.
You can't abstract it into a macro or function - i.e. in your forms have
something like
EXECUTE("SELECT * FROM " + FixName("MyTable"));
(bearing in mind I know nothing about Paradox)?
> If I get it working, I may update the ODBC driver form to
> have a couple
> of tick boxes to make this an option in the driver and send you the
> changes made.
OK, thanks. 1 tick box will probably do though :-)
Regards, Dave.
Dave Page wrote:
>
>
>
>
>>-----Original Message-----
>>From: pgsql-odbc-owner@postgresql.org
>>[mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane
>>Sent: 10 February 2005 14:32
>>To: pgsql-odbc@postgresql.org
>>Subject: Re: [ODBC] Compiling using Visual Studio 2003
>>
>>Dave Page wrote:
>>
>>
>>
>>>>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'm Thick. What is this file? It doesn't seem come with psqlodbc and
>>there is no mention of it in the doc on the GBORG site about
>>compiling
>>the driver. I was changing to the extracted dir & trying nmake.....
>>
>>
>
>It sets up the DOS environment for VC and is part of Visual Studio. On
>my system I have it in:
>
>C:\Program Files\Microsoft Visual Studio .NET 2003\Vc7\bin (VS.NET 2K3)
>
>And
>
>C:\Program Files\Microsoft Visual Studio\VC98\Bin (VS6)
>
>Note that if you can it's better to use VC++6 as the required runtimes
>are generally already on most machines.
>
>
Good show. I can now compile using the makefile. Maybe you can add this
info to run vcvar32.bat to the readme.txt file? I did read this file but
knew nothing about running the batch file beforehand (not knowing much
about visual studio).
>>I can fix it in code but this would break the compatibility of using
>>either the paradox tables or postgres tables. I would have to
>>have two
>>different versions of each form etc & record many lines of
>>code to say
>>"If in postgres add a public. to every table name" which is a
>>huge pest
>>& I don't want to have two version of each form to try & keep in sync
>>with each other.
>>
>>
>You can't abstract it into a macro or function - i.e. in your forms have
>something like
>
>EXECUTE("SELECT * FROM " + FixName("MyTable"));
>
>(bearing in mind I know nothing about Paradox)?
>
>
SQL querying in paradox is straight forward. I can just give it the name
of the table without any schema. It the rest of the interface & data
models which breaks things when schemas are present in the table names.
Querying Postgres is quite simple to get working but the data models are
another story. It's a bloody pest really. Sometimes I wish I knew
nothing about paradox as well!!
--
Paul Cochrane (paul.m.cochrane@tuht.scot.nhs.uk)
+--------------------------------------------------------
| Tayside Orthopaedic & Rehabilitation Technology Centre
| Ninewells Hospital & Medical School
| Dundee, Scotland, UK.
| DD1 9SY
| Phone: Internal: 36284
| External: +44 (1382) 496284
| Fax: +44 (1382) 496322
+--------------------------------------------------------
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Paul Cochrane > Sent: 10 February 2005 15:23 > To: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] Compiling using Visual Studio 2003 > > Good show. I can now compile using the makefile. Maybe you > can add this > info to run vcvar32.bat to the readme.txt file? I did read > this file but > knew nothing about running the batch file beforehand (not > knowing much > about visual studio). Glad it's working - I've updated the readme and the website. > SQL querying in paradox is straight forward. I can just give > it the name > of the table without any schema. It the rest of the interface & data > models which breaks things when schemas are present in the > table names. > Querying Postgres is quite simple to get working but the data > models are > another story. It's a bloody pest really. Sometimes I wish I knew > nothing about paradox as well!! Urgh :-( Regards, Dave.
Paul Cochrane wrote: > 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. Paul, you may find that recent versions of the driver no longer have the schema problem, eg 8.00.0004. Paradox uses the BDE for all data access, and I no longer have this problem with Delphi and the BDE. > My next problem which I'm working on at the moment is that the new > driver completely crashes with no error messages when opening certain > tables. I can open some but others simply crash paradox (no GPF no > nothing). All I get is 2 errors in the server log: could not receive > data from client: Connection reset by peer & > unexpected EOF on client connection. > > I'm not expecting you to solve this one at present. It may be paradox > being a bit flaky and nothing to do with the ODBC driver (although I > suspect it is). All I know is that it works with psqlodbc 7.3.200 & > postgres 7.2.X but isn't working with my compiled driver 8.0.4 and > postgres 8.0.1. I'm about to downgrade postgres to 7 to see if that > has any more luck. > Do you have Text (Memo) or blob columns by any chance?
David Brown wrote: > Paul Cochrane wrote: > >> 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. > > > Paul, you may find that recent versions of the driver no longer have > the schema problem, eg 8.00.0004. Paradox uses the BDE for all data > access, and I no longer have this problem with Delphi and the BDE. I can't get it it to work for long enough to even test it when schema are enabled (yet). It may work as standard but I doubt it. > >> My next problem which I'm working on at the moment is that the new >> driver completely crashes with no error messages when opening certain >> tables. I can open some but others simply crash paradox (no GPF no >> nothing). All I get is 2 errors in the server log: could not receive >> data from client: Connection reset by peer & >> unexpected EOF on client connection. >> >> I'm not expecting you to solve this one at present. It may be paradox >> being a bit flaky and nothing to do with the ODBC driver (although I >> suspect it is). All I know is that it works with psqlodbc 7.3.200 & >> postgres 7.2.X but isn't working with my compiled driver 8.0.4 and >> postgres 8.0.1. I'm about to downgrade postgres to 7 to see if that >> has any more luck. >> > Do you have Text (Memo) or blob columns by any chance? The original paradox tables did have memo fields. I converted them to a LONGVARCHAR (-1). Would this be a blob in Postgres? Is this a known problem? (He asks clutching at a handy straw beside the monitor) Paul -- Paul Cochrane (paul.m.cochrane@tuht.scot.nhs.uk) +-------------------------------------------------------- | Tayside Orthopaedic & Rehabilitation Technology Centre | Ninewells Hospital & Medical School | Dundee, Scotland, UK. | DD1 9SY | Phone: Internal: 36284 | External: +44 (1382) 496284 | Fax: +44 (1382) 496322 +--------------------------------------------------------