Re: problem with CVS version
От | Dave Page |
---|---|
Тема | Re: problem with CVS version |
Дата | |
Msg-id | E7F85A1B5FF8D44C8A1AF6885BC9A0E41A753B@ratbert.vale-housing.co.uk обсуждение исходный текст |
Ответ на | problem with CVS version ("Antonio Pennino" <a.pennino@nocerainformatica.net>) |
Ответы |
Re: problem with CVS version
|
Список | pgsql-odbc |
> -----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.
В списке pgsql-odbc по дате отправления: