headers
ljwilson | 19 May 2013 15:23
Favicon

Compiling psqlODBC on Windows with MS VC++ 2005 Express

With the latest psqlODBC 09.02.0100 prep, I have to make one change to
compile using MS VC++ 2005 Express (32-bit version of drivers):

In psqlodbc.h (my addition in bold)

/* File:			psqlodbc.h
 *
 * Description:		This file contains defines and declarations that are
related to
 *					the entire driver.
 *
 * Comments:		See "readme.txt" for copyright and license information.
 */

#ifndef __PSQLODBC_H__
#define __PSQLODBC_H__

/* #define	__MS_REPORTS_ANSI_CHAR__ */

#ifndef WIN32
#include "config.h"
#else
#define	WIN32_LEAN_AND_MEAN
#include <windows.h>
*#if (_MSC_VER == 1400) /* in case of VC++ 2005 */
#include <winsock2.h>
#endif /* _MSC_VER == 1400 */*
#endif

For a detailed discussion of why we need winsock2.h see:
(Continue reading)

Permalink | Reply | 5 comments |
headers
Hiroshi Inoue | 18 May 2013 00:37
Picon

Re: ODBC Blank Date convert to null

Hi Barry,

Thanks.
Isn't qo_deliver timestamp type?
If so, there's no such version that converts blank timestamp to null.

I've built a trial version.
Could you please try the dll on testing for 9.1.0300 at
  http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/index.html
setting the Extra Opts = 0x8?

regards,
Hiroshi Inoue

(2013/05/17 22:08), Barry Bell wrote:
> Error is (when putting a blank date into field qo_deliver
> "ERROR: invalid input syntax for type timestamp: "";\ aError while executing the query"
>
> vfp9            30e8-2f90	ENTER SQLExecDirect
> 		HSTMT               0x0036C4D8
> 		UCHAR *             0x0258E488 [      -3] "UPDATE HITS.DLPOINTS SET QO_DELIVER=? WHERE QO_ID=?\ 0"
> 		SDWORD                    -3
>
> vfp9            30e8-2f90	EXIT  SQLExecDirect  with return code -1 (SQL_ERROR)
> 		HSTMT               0x0036C4D8
> 		UCHAR *             0x0258E488 [      -3] "UPDATE HITS.DLPOINTS SET QO_DELIVER=? WHERE QO_ID=?\ 0"
> 		SDWORD                    -3
>
> 		DIAG [22007] ERROR: invalid input syntax for type timestamp: "";
> Error while executing the query (7)
(Continue reading)

Permalink | Reply | 0 comments |
headers
Barry Bell | 17 May 2013 19:57
Favicon

Postgres ODBC blank date

Hi:

   Currently when we put a blank date into a date/time field in postgres, we get a “Invalid data/time syntax” error.

Can you put a patch for the ODBC driver to convert the blank date to null?

 

(Other ODBC drivers we are doing do this and a previous ODBC drive 7.3.260 did support this?

 

Any way to add this to current version?

 

Thanks

Barry Bell, IT Department

Office: 954-429-3771 x267 Fax: 954-281-1464 email Barry_Bell <at> harte-hanks.com

 

Permalink | Reply | 0 comments |
headers
Barry Bell | 16 May 2013 22:07
Favicon

ODBC Blank Date convert to null


Does anyone know of an setting in the ODBC driver that will convert a blank date to a null?


Thanks
Barry 


--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 1 comment |
headers
barryrbell | 16 May 2013 21:32
Favicon

Re: ODBC blank date.time setting

Thanks, but the Extra Opts = 0x8 is not working on odbc version 9.2,
What was the last version where it worked?

--
View this message in context: http://postgresql.1045698.n5.nabble.com/ODBC-blank-date-time-setting-tp5742318p5755860.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 0 comments |
headers
Hiroshi Saito | 15 May 2013 16:51
Picon

Vote Release number of the next.

Hi.

I think the vote of the next release number.

1.) 09.01.0300
many patch is a bug-fix support. and, psqlODBC is not intended
to be synchronized with postgres version number.

2.) 09.02.0100
new version is desirable because test code that contains.

3.) 09.03.0100
we want to have a postgres release the next number.

==
I vote to 1.) , I think the major version up, when there is a
change of more features and desirable.
thanks!

Regards,
Hiroshi Saito

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 6 comments |
headers
Jan-Peter Seifert | 13 May 2013 16:04
Picon
Picon

Problem with special characters in password when using SQLDriverConnect


Hello,
 
if you use SQLDriverConnect instead of SQLConnect the connection fails on special characters like ';',
'(', ')' and '+'(?) within the password.
 
According to the documentation (
http://msdn.microsoft.com/en-us/library/windows/desktop/ms715433%28v=vs.85%29.aspx )
[]{}(),;?*=! <at>   are special characters.
 
In order to pass the connection string to the driver intact you have to bracket the whole connection string (
or just the values ? - it looks like my English is not good enough for this article ).
 
There already had been a patch in 09.00.0100 but this problem obviously persists in psqlODBC 09.01.0100
Unicode. Maybe this has been patched in the ANSI version only?

Backslashes are still a problem? I wonder whether standard_conforming_strings has an effect on embedded backslashes.
 
Could you check, please?
 
Thank you very much,
 
Peter

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 4 comments |
headers
Jan-Peter Seifert | 13 May 2013 15:15
Picon
Picon

psqlODBC 09.01.0100 Unicode version still crashes on long server messages?

Hello,
 
it seems when using the Unicode version of the driver it crashes when: log_statement = 'all' client_min_messages < notice
and a long query ( e.g. create function ) is sent to the server.
 
Did not test it with a long erronous query sent to the server without using the settings above. But I guess this would cause the driver to crash as well.
 
Back in psqlODBC v08.04.0200 ANSI there was a crash when the server message was longer than ~4096 bytes.
 
I guess this had been fixed in v09.00.0100 with this patch:
6.) Removed the use of misused strcat_s together with snprintf_s (bug report from Jap-Peter Seifert) and use strlcat instead of strncat.
 
Could it be that this had been fixed in the ANSI version only?
 
Sorry if this had already been fixed in recent versions.
 
Could you check, please?
 
Thank you very much!
 
Peter
 
 
 
Permalink | Reply | 2 comments |
headers
Carlos Muñoz Juste | 13 May 2013 11:21

Issue with Oracle Database Gateway for ODBC and Unicode

Hello,

I hope this is the right mailing list to post questions about pgsql odbc. I am sorry if I made a mistake and it is not.

I have a Postgres database (9.1) and an Oracle database (10.2) whose character set is utf8. I installed the 64-bit 9.1 unicode psqlodbc driver along with the Oracle Database Gateway for ODBC (DG4ODBC), version 11.2 because I have the need to access data in the Postgres database from the Oracle one.

It works fine, but we have noticed the following. When a query such as this is issued in Oracle:

select * from "dps_user" <at> pg where "id" = '32422'

The where clause is dropped, and the query that reaches the Postgres database is:

select * from "dps_user"

So the whole table data are brought from Postgres, and then the where clause is applied in Oracle. This is pretty inefficient with big tables.

We have noticed that this only happens when the column in the where clause is of type character varying, due to the fact that the Oracle Database Gateway for ODBC returns all character varying columns in Postgres as type NVARCHAR2. If we issue the query like this, then the where clause is passed to Postgres:

select * from "dps_user" <at> pg where "id" = cast('32422' as nvarchar2(40))

This behavior does not happen when we used the psqlodbc ANSI driver, but unfortunately the Unicode driver is a must because both databases contain Japanese, Russian and Chinese characters. It does not happen either when we access the Postgres database through the psqlodbc Unicode driver from, for example, Microsoft Query, so it has something to do with the Oracle Database Gateway.

However, I thought I would post my problem here, just in case you ran into this problem or heard of someone who did. Having to use the cast as nvarchar2 works, but it is very cumbersome. I wonder if there would be a way to configure the psqlodbc driver so that a varchar2 column is returned instead.

I am going to open a service request with Oracle to see if they can help me on the gateway end.

Sorry again if this is not the right place for this question.

Thanks a lot,

Carlos
Permalink | Reply | 2 comments |
headers
ljwilson | 10 May 2013 20:27
Favicon

Are UseDeclareFetch and UseServerSidePrepare mutually exclusive?

I've seen conflicting information on this:
http://postgresql.1045698.n5.nabble.com/Improve-ODBC-Throughput-tp2189601p2189614.html
<http://postgresql.1045698.n5.nabble.com/Improve-ODBC-Throughput-tp2189601p2189614.html>  

What I see with the latest source tree in my test environment of two windows
workstations, each using the latest compiled odbc drivers (09.01.02??) to
connect to PostgreSQL 9.2.4 (Windows):

1. With UserDeclareFetch=1 and UseServerSidePrepare=0, works as it always
has for me.
2. With UserDeclareFetch=0 and UseServerSidePrepare=1, works as it always
has for me.
3. With UserDeclareFetch=1 and UseServerSidePrepare=1, the first workstation
that opens the database "wins". Then the second workstation cannot open the
database on its own connection until the first workstation exits its
program.

If I use pgadmin3 to monitor a table--if a workstation with
UserDeclareFetch=1 and UseServerSidePrepare=1 enters data into the table,
pgadmin3 will not show the new data until the workstation exits. It's like
the workstation has an exclusive lock on the table when UserDeclareFetch=1
and UseServerSidePrepare=1.

I'm not questioning the behavior, but I'd like to understand it and maybe
get it documented so a user doesn't accidentally set up the switches such
that it takes a while to figure out what is going on.

Thanks...jack

--
View this message in context: http://postgresql.1045698.n5.nabble.com/Are-UseDeclareFetch-and-UseServerSidePrepare-mutually-exclusive-tp5755080.html
Sent from the PostgreSQL - odbc mailing list archive at Nabble.com.

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 5 comments |
headers
Heikki Linnakangas | 2 May 2013 08:54
Favicon

Time for a 9.3 release?

If everything goes to the plan, PostgreSQL 9.3 beta will be released in 
the new few weeks, and I just saw a thread on the pgsql-jdbc list on 
releasing a 9.3 JDBC driver for the beta 
(http://www.postgresql.org/message-id/1367433610.6768.15.camel <at> lenovo01-laptop03.gunduz.org).

I think we should also make a 9.3 release of the ODBC driver. There's 
been a lot of bug fixes since the last release, so it's time to make a 
new release anyway.

- Heikki

--

-- 
Sent via pgsql-odbc mailing list (pgsql-odbc <at> postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Permalink | Reply | 10 comments |

Gmane