Thread: problem with CVS version

problem with CVS version

From
"Antonio Pennino"
Date:
I Have problem(s) with the CVS version of psqldobc.dll.

At the server side i have Postgresql 7.2.1 on Debian.

With a table as it:

=========================================================
firedell=# \d hosts
                      Table "hosts"
  Column  |         Type          |      Modifiers
----------+-----------------------+----------------------
 nicknome | character varying(16) | not null
 hostnome | character varying(32) | not null
 note     | character varying(50) | not null default '-'
Primary key: hosts_pkey
Unique keys: hosts_hostnome_key
Triggers: tr_aggiorna_tabelle_dipendenti
=========================================================

at the client (win98) all the three columns are so readed:
(MFC m_rgODBCFieldInfos structure, using HOSTNOME for example):

        m_strName       hostnome    (OK)
        m_nSQLType      -9          (!!!)
        m_nPrecision    32          (OK)
        m_nScale        0
        m_nNullability  0

Please note: also with Access97 i have problem (with no detail)
if a try a link a database, is not go to show the table list.

If a use the older (07.03.0208 version, 7/1/2004) all is ok.
My MDAC version *maybe* 2.71

Please help...

       Antonio.


============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version

From
"Dave Page"
Date:
Hi,

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Antonio Pennino
> Sent: 23 July 2004 14:42
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] problem with CVS version
>
>
>         m_strName       hostnome    (OK)
>         m_nSQLType      -9          (!!!)

-9 == SQL_WVARCHAR. The driver now supports Unicode so will return
SQL_W* where appropriate (I'm not sure of the exact rules as I didn't
write the code.

>         m_nPrecision    32          (OK)
>         m_nScale        0
>         m_nNullability  0
>
> Please note: also with Access97 i have problem (with no detail)
> if a try a link a database, is not go to show the table list.

Yup, just found a bug in there (well, I found a bug with Access 2K3 - I
assume it's the same one). Can I send you an updated dll to test?

Regards, Dave

Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: Antonio Pennino [mailto:a.pennino@nocerainformatica.net]
> Sent: 26 July 2004 16:11
> To: Dave Page
> Subject: RE: [ODBC] problem with CVS version
>
> Subject:            RE: [ODBC] problem with CVS version
> Date sent:          Mon, 26 Jul 2004 15:25:19 +0100
> From:               "Dave Page" <dpage@vale-housing.co.uk>
> To:                 "Antonio Pennino"
> <a.pennino@nocerainformatica.net>
>
> > Attached - please let me know if you have any more problems.
>
> sorry, not work. It is better but not OK.
>
> Now i can see the "linked table" into MS-Access (97) but in the
> grid i see "#Eliminato". The table structure (columns and type)
> are correctly showed.
>
> By using my program for make the dump of the tables, some
> column not are dumped.
>
> In this reply i have attached the logs you have requested.
>
> It contain the open of database (ms-access 97, the show of the
> table grid (filled of "#eliminato") and the close of the db.

Hmm, there's nothing in there that looks odd to me, but then I've never
dug quite this deep into the driver before. I assume '#eliminato'
translates to '#deleted'? If so, I believe this is a common problem on
Access, though I'm not sure of the solution.  Perhaps someone else on
the list can shed some light.

Meanwhile, I'm looking for a copy of Access 97 to test with, but so far
it's beginning to look like we have got rid of them all :-( If anyone
else has it and can test a dev build of the driver for us, please let me
know and I'll send a copy of the dll.

Regards, Dave

Re: problem with CVS version

From
"Antonio Pennino"
Date:
Subject:            RE: [ODBC] problem with CVS version
Date sent:          Tue, 27 Jul 2004 13:27:30 +0100
From:               "Dave Page" <dpage@vale-housing.co.uk>
To:                 "Antonio Pennino" <a.pennino@nocerainformatica.net>
Copies to:          <pgsql-odbc@postgresql.org>

> Hmm, there's nothing in there that looks odd to me, but then I've never
> dug quite this deep into the driver before. I assume '#eliminato'
> translates to '#deleted'?

Yes, but is NOT only a MS-ACCESS 97 problem because
with my dump utility a see m_nSQLType (MFC) = -9 !!!

This variabile is obtained from ::SQLDescribeCol(), this  MFC
fragment show who MFC use this API:

AFX_ODBC_CALL(::SQLDescribeCol(m_hstmt,
                 n,
            (UCHAR*)lpszFieldName,
                 MAX_FNAME_LEN,
                 &nActualLen,
            &m_rgODBCFieldInfos[n - 1].m_nSQLType,
            &m_rgODBCFieldInfos[n - 1].m_nPrecision,
            &m_rgODBCFieldInfos[n - 1].m_nScale,
            &m_rgODBCFieldInfos[n - 1].m_nNullability));


I may send the source of my utility if someone want it.
It require Microsoft Visual Studio 6.

Perhaps the ::SQLDescribeCol() is deprecated for psql but MFC
use it and i CAN NOT write my code without the MFC framework.

If, instead of the CVS version and/or the beta version from
Dave, i use an older (7.1.2004) version of psqlodbc.dll,
m_nSQLType is = 12.

The server is the 7.2.1

Thanks for any help.


============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: Antonio Pennino [mailto:a.pennino@nocerainformatica.net]
> Sent: 27 July 2004 14:18
> To: Dave Page
> Cc: pgsql-odbc@postgresql.org
> Subject: RE: [ODBC] problem with CVS version
>
> Subject:            RE: [ODBC] problem with CVS version
> Date sent:          Tue, 27 Jul 2004 13:27:30 +0100
> From:               "Dave Page" <dpage@vale-housing.co.uk>
> To:                 "Antonio Pennino"
> <a.pennino@nocerainformatica.net>
> Copies to:          <pgsql-odbc@postgresql.org>
>
> > Hmm, there's nothing in there that looks odd to me, but then I've
> > never dug quite this deep into the driver before. I assume
> '#eliminato'
> > translates to '#deleted'?
>
> Yes, but is NOT only a MS-ACCESS 97 problem because with my
> dump utility a see m_nSQLType (MFC) = -9 !!!

As I said, -9 is SQL_WVARCHAR which is a perfectly valid type. Your
application is calling the *W version of various SQL functions (or the
driver manager is mapping your calls to them because it is detecting
that your app is Unicode aware - as per the ODBC spec), so it should be
able to recognise a unicode data type.

> Perhaps the ::SQLDescribeCol() is deprecated for psql but MFC
> use it and i CAN NOT write my code without the MFC framework.

SQLDescribeCol is most certainly supported.

> If, instead of the CVS version and/or the beta version from
> Dave, i use an older (7.1.2004) version of psqlodbc.dll,
> m_nSQLType is = 12.

Yes, because the older driver did not support unicode.

Regard, Dave.

Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: Dave Page
> Sent: 27 July 2004 21:34
> To: 'Antonio Pennino'
> Subject: RE: [ODBC] problem with CVS version
>
>
> The behaviour you see is correct when calling
> SQLDescribeColW, however, I did just test this using ANSI
> ODBC Test and it is also returning -9 which is not correct.
> I'm not convinced this will resolve your problem, but it
> certainly isn't right. I'll look into it some more...

OK, I've traced this through the code, and as far as I can see it is
just fine. If the connection is made using SQLConnectW,
SQLDriverConnectW or SQLBrowseConnectW, then a unicode flag in the
connection object is set. When a PostgreSQL type is later converted to
an ODBC type (as happens for SQLDescribeCol), that flag is checked. The
following rules apply:

If the column length exceeds max_varchar_size, if the unicode flag is
set, SQL_WLONGVARCHAR is returned, otherwise SQL_LONGVARCHAR is
returned. If the column length does not exceed max_varchar_size, if the
unicode flag is set, SQL_WVARCHAR is returned, otherwise SQL_VARCHAR is
returned.

I believe the ANSI ODBC Test program is giving a bit of a red herring.
The SQL trace log shows it calling SQLConnectW:

odbcte32        d10-d14    ENTER SQLDriverConnectW
        HDBC                003A1510
        HWND                00140560
        WCHAR *             0x1F7A9D2C [      -3] "******\ 0"
        SWORD                       -3
        WCHAR *             0x1F7A9D2C
        SWORD                        2
        SWORD *             0x00000000
        UWORD                        1 <SQL_DRIVER_COMPLETE>

Therefore it's no surprise that the driver thinks it's OK to return
unicode datatypes.

Regards, Dave.

Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: Antonio Pennino [mailto:a.pennino@nocerainformatica.net]
> Sent: 27 July 2004 16:17
> To: Dave Page
> Subject: RE: [ODBC] problem with CVS version
>
>
> > Yes, because the older driver did not support unicode.
>
> my application is NOT unicode (never i have used unicode) and
> the table on the server not contain unicode fields but only
> "character varying(xx)".

Character varying(xx) may well be unicode depending on how your database
was created. With regard to your application, the ODBC Driver *Manager*
(ie. not the driver) will map function calls to the unicode version of
the functions (such as SQLDescribeColW) if it detects that your
application is unicode aware. Could it be the case that the MFC classes
you are using are unicode aware and the DM is detecting this?

Whatever the case though, the log file you supplied showed that you are
using the unicode functions (intentionally or not), therefore you should
expect to get unicode data types from the driver where appropriate.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/odbc/ht
m/odbcunicode_applications.asp

> Is possible to force the driver for
> not use unicode?

I assume you can just call SQLDescribeColA (or the A version of other
functions). This whole unicode/odbc thing is new to me anyway - I'm only
really trying to help out with ODBC bugs in the absence of anyone else
who *really* knows ODBC inside out, and I don't really have any personal
interest in ODBC these days anyway.

Regards, Dave.

Re: problem with CVS version

From
"Antonio Pennino"
Date:
> If the connection is made using SQLConnectW,
> SQLDriverConnectW or SQLBrowseConnectW,

I am *sure* : i not call unicode API.

Ok, is a problem of the driver manager.
The MDAC update not solve the problem.

The database is not unicode:

firedell:/etc/postgresql# psql -l

        List of databases
   Name    |  Owner   | Encoding
-----------+----------+-----------
 dbrete    | postgres | SQL_ASCII
 firedell  | postgres | SQL_ASCII
 template0 | postgres | SQL_ASCII
 template1 | postgres | SQL_ASCII

One table (with varchar also) is read ok, the other 4 no!

Building the connection string (via a .udl file) it is:

DSN=firedell;DATABASE=firedell;SERVER=192.168.160.254;PORT=5432
;UID=postgres;PWD=<omissis>;ReadOnly=0;Protocol=6.4;FakeOidInde
x=0;ShowOidColumn=0;RowVersioning=0;ShowSystemTables=0;ConnSett
ings=;Fetch=100;Socket=4096;UnknownSizes=0;MaxVarcharSize=254;M
axLongVarcharSize=8190;Debug=1;CommLog=0;Optimizer=1;Ksqo=1;Use
DeclareFetch=1;TextAsLongVarchar=0;UnknownsAsLongVarchar=0;Bool
sAsChar=0;Parse=1;CancelAsFreeStmt=0;ExtraSysTablePrefixes=dd_;
;LFConversion=1;UpdatableCursors=0;DisallowPremature=0;TrueIsMi
nus1=0;BI=0;ByteaAsLongVarBinary=0;UseServerSidePrepare=0

Why Protocol=6.4 when i have set it to 7.x? the server is 7.2.x

Sorry for yours time.... and for my time also :-))


============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Antonio Pennino
> Sent: 28 July 2004 19:45
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] problem with CVS version
>
> > If the connection is made using SQLConnectW, SQLDriverConnectW or
> > SQLBrowseConnectW,
>
> I am *sure* : i not call unicode API.

OK.

> Ok, is a problem of the driver manager.
> The MDAC update not solve the problem.

Yes, I think it is the DM. I just tried using the Ansi ODBC Test program
with the SQL Server driver. It called the Unicode functions as well...

odbcte32        828-170    ENTER SQLDriverConnectW
        HDBC                003A17D8
        HWND                00040396
        WCHAR *             0x1F7A9D2C [      -3] "******\ 0"
        SWORD                       -3
        WCHAR *             0x1F7A9D2C
        SWORD                        2
        SWORD *             0x00000000
        UWORD                        1 <SQL_DRIVER_COMPLETE>

odbcte32        828-170    EXIT  SQLDriverConnectW  with return code 1
(SQL_SUCCESS_WITH_INFO)
        HDBC                003A17D8
        HWND                00040396
        WCHAR *             0x1F7A9D2C [      -3] "******\ 0"
        SWORD                       -3
        WCHAR *             0x1F7A9D2C
        SWORD                        2
        SWORD *             0x00000000
        UWORD                        1 <SQL_DRIVER_COMPLETE>

        DIAG [01000] [Microsoft][ODBC SQL Server Driver][SQL
Server]Changed database context to 'uhlive'. (5701)


> The database is not unicode:
>
> firedell:/etc/postgresql# psql -l
>
>         List of databases
>    Name    |  Owner   | Encoding
> -----------+----------+-----------
>  dbrete    | postgres | SQL_ASCII
>  firedell  | postgres | SQL_ASCII
>  template0 | postgres | SQL_ASCII
>  template1 | postgres | SQL_ASCII
>
> One table (with varchar also) is read ok, the other 4 no!
>

The difference with SQL Server is that it has separate types for
unicode/non-unicode data (nvarchar/varchar) which can be mixed in the
same table. I don't fully understand what the possible side effects
might be yet, but what if we only set conn->unicode if the connection is
made to a unicode database AND the driver tries to call SQL*ConnectW?

Comments anyone?

> Why Protocol=6.4 when i have set it to 7.x? the server is 7.2.x

7.2.x uses the 6.4 protocol. That's normal :-)

Regards, Dave.

Re: problem with CVS version

From
"Antonio Pennino"
Date:
Subject:            RE: [ODBC] problem with CVS version
Date sent:          Thu, 29 Jul 2004 08:46:02 +0100
From:               "Dave Page" <dpage@vale-housing.co.uk>
To:                 "Antonio Pennino" <a.pennino@nocerainformatica.net>,
      <pgsql-odbc@postgresql.org>

> Yes, I think it is the DM.

the solution *should* be the SQLSetConnectAttr().
No, it not work... my code is this:

_______________________________________________________________

   long numero = SQL_AA_TRUE;
   int  valore = 0;
   short shval = 0;
   long native = 0;
   SQLRETURN r = 0;
   int       n = 0;

   char  state[8] ; memset(state,0,sizeof(state));
   char  text[99] ; memset( text,0,sizeof(text));

   /**/ r = SQLSetConnectAttr(hdbc,SQL_ATTR_ANSI_APP,  // <<-!
                                     (SQLPOINTER)&numero,
                                     valore);

   if  (r)
   {
        r = SQLGetDiagRec(SQL_HANDLE_DBC,hdbc,1 ,
                              (unsigned char *) state,
                              &native,
                              (unsigned char *) text,
                              sizeof(text),&shval);
   }

_______________________________________________________________

The result are:

   a) the SQLSetConnectAttr() return -1

   b) the SQLGetDiagRec() return:

        . state = "S1092"
        . text  = "[...][...] Option type out of range"

Identical result i have with ms-access, perhaps are wrong the
arguments? I have take the idea from here:

http://publib.boulder.ibm.com/infocenter/db2v8luw/
       index.jsp?topic=/com.ibm.db2.udb.doc/ad/c0008616.htm



============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version

From
Janet Borschowa
Date:
Hi,
The driver manager maps ODBC API calls with unicode drivers as shown below.
Please note that this is why the trace file shows calls to
SQLDriverConnectW, etc. The SQL Server ODBC driver is a unicode driver. You
may want to read the Microsoft ODBC Programmer's Reference for more
information about programming in the presence of a unicode driver (its
available online from Microsoft's website) and that may help you solve your
problem.

From my reading of the docs, it looks like if SQLDescribeCol is returning
SQL_WVARCHAR you should not have any problem binding that column with
SQL_C_CHAR and retrieving the data. If you are, then there is a bug in the
driver OR there is a problem with the codesets in use on the server and/or
the client which prevents the wchar data from being converted to char data.

Sorry I can't help more but I don't have the time to debug the problem.

----------------------------------------------------------------------------
------------------------
Unicode Drivers
Whether a driver should be a Unicode driver or an ANSI driver depends
entirely on the nature of the data source. If the data source supports
Unicode data, the driver should be a Unicode driver. If the data source only
supports ANSI data, the driver should remain an ANSI driver.

A Unicode driver must export SQLConnectW in order to be recognized as a
Unicode driver by the Driver Manager.

A Unicode driver must accept Unicode functions (with a suffix of W) and
store Unicode data. It can also accept ANSI functions, but is not required
to. (The Driver Manager does not pass an ANSI function call with the A
suffix to the driver, but converts it to an ANSI function call without the
suffix and then passes it to the driver.)

A Unicode driver must be able to return result sets in either Unicode or
ANSI, depending on the application's binding. If an application binds to
SQL_C_CHAR, the Unicode driver must convert SQL_WCHAR data to SQL_CHAR. The
driver manager will map SQL_C_WCHAR to SQL_C_CHAR for ANSI drivers but does
no mapping for Unicode drivers.

Note   When determining the driver type, the Driver Manager will call
SQLSetConnectAttr and set the SQL_ATTR_ANSI_APP attribute at connection
time. If the application is using ANSI APIs, SQL_ATTR_ANSI_APP will be set
to SQL_AA_TRUE, and if it is using Unicode, it will be set to a value of
SQL_AA_FALSE. This attribute is used so that the driver can exhibit
different behavior based on the application type. The attribute cannot be
set by the application directly, and it is not supported by
SQLGetConnectAttr. If a driver exhibits the same behavior for both ANSI and
Unicode applications, it should return SQL_ERROR for this attribute. If the
driver returns SQL_SUCCESS, the Driver Manager will separate ANSI and
Unicode connections when Connection Pooling is used.
----------------------------------------------------------------------------
------------------------

========================
Janet Borschowa
Software Engineer, Database Products
Rogue Wave Software, a QUOVADX(tm) Division
(541) 753-1931   FAX: (541) 757-4630
mailto:borschow@roguewave.com  http://www.roguewave.com




> -----Original Message-----
> From: Dave Page [mailto:dpage@vale-housing.co.uk]
> Sent: Thursday, July 29, 2004 12:46 AM
> To: Antonio Pennino; pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] problem with CVS version
>
>
>
>
> > -----Original Message-----
> > From: pgsql-odbc-owner@postgresql.org
> > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of
> Antonio Pennino
> > Sent: 28 July 2004 19:45
> > To: pgsql-odbc@postgresql.org
> > Subject: Re: [ODBC] problem with CVS version
> >
> > > If the connection is made using SQLConnectW, SQLDriverConnectW or
> > > SQLBrowseConnectW,
> >
> > I am *sure* : i not call unicode API.
>
> OK.
>
> > Ok, is a problem of the driver manager.
> > The MDAC update not solve the problem.
>
> Yes, I think it is the DM. I just tried using the Ansi ODBC
> Test program with the SQL Server driver. It called the
> Unicode functions as well...
>
> odbcte32        828-170    ENTER SQLDriverConnectW
>         HDBC                003A17D8
>         HWND                00040396
>         WCHAR *             0x1F7A9D2C [      -3] "******\ 0"
>         SWORD                       -3
>         WCHAR *             0x1F7A9D2C
>         SWORD                        2
>         SWORD *             0x00000000
>         UWORD                        1 <SQL_DRIVER_COMPLETE>
>
> odbcte32        828-170    EXIT  SQLDriverConnectW  with
> return code 1
> (SQL_SUCCESS_WITH_INFO)
>         HDBC                003A17D8
>         HWND                00040396
>         WCHAR *             0x1F7A9D2C [      -3] "******\ 0"
>         SWORD                       -3
>         WCHAR *             0x1F7A9D2C
>         SWORD                        2
>         SWORD *             0x00000000
>         UWORD                        1 <SQL_DRIVER_COMPLETE>
>
>         DIAG [01000] [Microsoft][ODBC SQL Server
> Driver][SQL Server]Changed database context to 'uhlive'. (5701)
>
>
> > The database is not unicode:
> >
> > firedell:/etc/postgresql# psql -l
> >
> >         List of databases
> >    Name    |  Owner   | Encoding
> > -----------+----------+-----------
> >  dbrete    | postgres | SQL_ASCII
> >  firedell  | postgres | SQL_ASCII
> >  template0 | postgres | SQL_ASCII
> >  template1 | postgres | SQL_ASCII
> >
> > One table (with varchar also) is read ok, the other 4 no!
> >
>
> The difference with SQL Server is that it has separate types
> for unicode/non-unicode data (nvarchar/varchar) which can be
> mixed in the same table. I don't fully understand what the
> possible side effects might be yet, but what if we only set
> conn->unicode if the connection is made to a unicode database
> AND the driver tries to call SQL*ConnectW?
>
> Comments anyone?
>
> > Why Protocol=6.4 when i have set it to 7.x? the server is 7.2.x
>
> 7.2.x uses the 6.4 protocol. That's normal :-)
>
> Regards, Dave.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 7: don't forget to increase your free space map settings
>

Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: Janet Borschowa [mailto:borschow@roguewave.com]
> Sent: 29 July 2004 20:22
> To: Antonio Pennino; pgsql-odbc@postgresql.org
> Cc: Dave Page
> Subject: RE: [ODBC] problem with CVS version
>
> Hi,
> The driver manager maps ODBC API calls with unicode drivers
> as shown below.
> Please note that this is why the trace file shows calls to
> SQLDriverConnectW, etc. The SQL Server ODBC driver is a
> unicode driver.

That's how the DM recognises a unicode driver. It also recognises
unicode applications, and *should* map function calls to the appropriate
unicode or ansi function (at least that's how I read the docs):

-----
You can recompile an application as a Unicode application in one of two
ways:

- Include the Unicode #define contained in the Sqlucode.h header file in
the application.
- Compile the application with the compiler's Unicode option. (This
option will be different for different compilers.)

To convert an ANSI application to a Unicode application, write the
application to store and pass Unicode data. In addition, calls to
functions that support SQLPOINTER arguments must be converted to use
count of bytes.

Once an application is compiled as a Unicode application, if the
application calls an ODBC API function (without a suffix), the Driver
Manager recognizes the application as a Unicode application and converts
the function call to a Unicode function (with the W suffix) if the
underlying driver supports Unicode. When an ANSI application makes a
function call without a suffix, the Driver Manager converts it to ANSI
if the underlying driver supports ANSI. If both the application and the
driver support the same character encoding, the driver manager passes
the calls through to the driver (with certain exceptions for ANSI
applications).
-----

From that, I would expect the ANSI ODBC Test program, supplied by
Microsoft to a) not explicitly call *W functions, and b) have
un-suffixed calls mapped to the ANSI version of the function by the DM.

> You may want to read the Microsoft ODBC
> Programmer's Reference for more information about programming
> in the presence of a unicode driver (its available online
> from Microsoft's website) and that may help you solve your problem.

I've spend quite some time reading the docs - I don't just make stuff up
:-)

Regards, Dave.

Re: problem with CVS version

From
"Dave Page"
Date:

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Antonio Pennino
> Sent: 29 July 2004 16:33
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] problem with CVS version
>
>
> Identical result i have with ms-access, perhaps are wrong the
> arguments? I have take the idea from here:
>
> http://publib.boulder.ibm.com/infocenter/db2v8luw/
>        index.jsp?topic=/com.ibm.db2.udb.doc/ad/c0008616.htm

Yeah - sounds good, but on further investigation, that's an ODBC 3.51
thing. I've added it to CVS anyway (#ifdef (ODBCVER >= 0x0351) of
course), but the DM still doesn't try to set it, even with the driver
compiled as 3.51 :-(.

I also considered the option of checking the DB encoding and setting
conn->unicode = 0 if it's not unicode, but then realised that's not a
good idea because it'll prevent the server recoding other charactersets
to unicode on the fly.

What happens if you explicitly call SQLConnectA rather than SQLConnect
in your application? Or, as Janet suggested, bind to the column as
SQL_C_CHAR even if it's SQL_WVARCHAR?

Regards, Dave.

Re: problem with CVS version

From
"Antonio Pennino"
Date:
Subject:            Re: [ODBC] problem with CVS version
Date sent:          Fri, 30 Jul 2004 14:03:17 +0100
From:               "Dave Page" <dpage@vale-housing.co.uk>
To:                 "Antonio Pennino" <a.pennino@nocerainformatica.net>,
      <pgsql-odbc@postgresql.org>

> What happens if you explicitly call SQLConnectA rather than SQLConnect
> in your application? Or, as Janet suggested, bind to the column as
> SQL_C_CHAR even if it's SQL_WVARCHAR?
>

no, i use ODBC via the MFC framework. Even if yours suggest
resolve the problem, it make a bigger problem to me: rewrite
ours projects :-)

May be a compile problem? With a nmake -f win32.mak ... i see:

   Building the PostgreSQL Unicode 3.0 Driver for Win32...

Is possible disable at compile-time the UNICODE support?


============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version

From
"Dave Page"
Date:


-----Original Message-----
From: pgsql-odbc-owner@postgresql.org on behalf of Antonio Pennino
Sent: Fri 7/30/2004 7:29 PM
To: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] problem with CVS version

> Is possible disable at compile-time the UNICODE support?

Not any more. You'll need to stick with an older version of the driver if you want a non-unicode version.

Regards, Dave.

Re: problem with CVS version

From
"Antonio Pennino"
Date:
From:               "Antonio Pennino" <a.pennino@nocerainformatica.net>
Organization:       Nocera Informatica
To:                 pgsql-odbc@postgresql.org
Date sent:          Fri, 30 Jul 2004 20:29:25 +0200
Subject:            Re: [ODBC] problem with CVS version

> What happens if you explicitly call SQLConnectA

problem solved!

I have modified the psqlodbc_win32.def REMOVING all entries for
the UNICODE functions. It is not the best, but i not found any
other...





============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


Re: problem with CVS version (Msg-ID: <41237349.3061.12DF040@localhost>)

From
"Antonio Pennino"
Date:
Date sent:          Fri, 30 Jul 2004 20:29:25 +0200
Subject:            Re: [ODBC] problem with CVS version

> What happens if you explicitly call SQLConnectA

problem solved!

I have modified the psqlodbc_win32.def REMOVING all entries for
the UNICODE functions. It is not the best, but i not found any
other...





============================================
Antonio Pennino
Nocera Informatica s.r.l.

telefono: 035/4219033
telefax : 035/4219050

e-mail  : a.pennino@nocerainformatica.net
============================================


---------------------------(end of broadcast)---------------------------
TIP 6: Have you searched our list archives?

               http://archives.postgresql.org

I post to the odbc list because ODBC users are mostly windows users
as well :) - sorry for the inconvenience.

I installed the latest cygwin including postgresql.

Everything is just fine, even the database is created on the path (see
example below).

But when trying to start postmaster an error happens.
The service installed wouldn't start as well.

Everything is done as the latest readme, the new cygipc replacement is
installed and running, etc....

Ideas found on internet sites are not working.

OS is Win2000 Server.

thanks for any help

Robert




-------------------------------------------------------------------------------
gabor@gabornb ~
$ /usr/bin/postmaster -D /usr/local/psql/data
WARNING:  dup(0) failed after 3196 successes: Bad file descriptor
C:\cygwin\bin\postgres.exe (2840): *** MapViewOfFileEx (0xF10000), Win32
error 4
87.  Terminating.
C:\cygwin\bin\postgres.exe (2820): *** MapViewOfFileEx (0xF10000), Win32
error 4
87.  Terminating.
LOG:  statistics collector process (PID 2840) exited with exit code 1
LOG:  startup process (PID 2820) exited with exit code 1
LOG:  aborting startup due to startup process failure

gabor@gabornb ~
$