Thread: problem with CVS version
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
============================================
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
> -----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
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
============================================
> -----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.
> -----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.
> -----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.
> 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
============================================
> -----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.
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
============================================
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 >
> -----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.
> -----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.
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
============================================
-----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.
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 ~ $