http://permalink.gmane.org/gmane.comp.db.postgresql.odbc hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9506 <pre>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: </pre> Hiroshi Inoue 2013-05-17T22:37:43 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9505 <pre>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&lt; at &gt;harte-hanks.com&lt;mailto:Barry_Bell&lt; at &gt;harte-hanks.com&gt; </pre> Barry Bell 2013-05-17T17:57:21 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9504 <pre>Now that I understand the version history a little better, I'm changing my vote for the next psqlodbc release number to 09.02.0100 . Thanks...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/Vote-Release-number-of-the-next-tp5755600p5755961.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com. </pre> ljwilson 2013-05-17T12:16:44 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9503 <pre> Now I'm inclined to 9.2.0100. Version 9.2 should have been released before and then the next release would be the last release of 9.2. regards, Hiroshi Inoue </pre> Inoue, Hiroshi 2013-05-17T03:55:50 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9502 <pre>Hi Barry, (2013/05/17 5:07), Barry Bell wrote: Are you using Unicode driver? Could you send me the Mylog output of the case? regards, Hiroshi Inoue </pre> Inoue, Hiroshi 2013-05-17T03:25:25 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9501 <pre> Does anyone know of an setting in the ODBC driver that will convert a blank date to a null? Thanks Barry </pre> Barry Bell 2013-05-16T20:07:59 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9500 <pre>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. </pre> barryrbell 2013-05-16T19:32:12 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9499 <pre>Hi, (2013/05/16 22:48), Jan-Peter Seifert wrote: Yes it's essentially the same code. The psqlodbc driver expects Percent-Encoding for the password option as well as the *Connect Settings* option unless the value is enclosed with braces. The driver can't distinguish the first '}' from the terminating bracket. Please look at http://msdn.microsoft.com/en-us/library/ms130822.aspx . </pre> Hiroshi Inoue 2013-05-16T14:58:46 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9498 <pre> Hello, That this has been fixed in the ANSI version only was just an assumption on my side, because the sudden increase of the 'known critical' characters seemed to be connected to the switch to the Unicode version of psqlODBC. It looks like the Unicode and the ANSI version use the 'same' internal functions though? Thank you very much for the patch! We tested several passwords in connection with the SQLDriverConnect function and the Unicode version of psqlODBC: password: %2 (two chars!) submitted as: …;UID=user;PWD=%2; fails …;UID=user;PWD={%2}; works password: %25 (three chars!) …;UID=user;PWD=%25; fails …;UID=user;PWD={%25}; works password: }{ …;UID=user;PWD={}{}; fails password: abc …;UID=user;PWD=abc; works (as expected) …;UID=user;PWD={abc}; works Password: a;bc …;UID=user;PWD=a;bc; fails (as expected) …;UID=user;PWD={a;bc}; works Best regards, Peter </pre> Jan-Peter Seifert 2013-05-16T13:48:27 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9497 <pre>Which, btw, means it should really be 09.02.0100, unless we're going to change the scheme. On Thu, May 16, 2013 at 8:22 AM, Dave Page &lt;dpage&lt; at &gt;pgadmin.org&gt; wrote: </pre> Dave Page 2013-05-16T07:22:58 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9496 <pre> Yes it is - we used to have some users get confused about what they should use, so we decided to link the version number to the current database server version number. There is no technical reason for linking them. -- Dave Page Blog: http://pgsnake.blogspot.com Twitter: &lt; at &gt;pgsnake EnterpriseDB UK: http://www.enterprisedb.com The Enterprise PostgreSQL Company </pre> Dave Page 2013-05-16T07:22:20 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9495 <pre>I also vote for 09.01.0300. I thought since we were compiling with 9.1 PostgreSQL headers that is where the "09.01" came from, or is that just a happy coincidence? Thanks...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/Vote-Release-number-of-the-next-tp5755600p5755696.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com. </pre> ljwilson 2013-05-15T23:36:14 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9494 <pre>Hi, (2013/05/13 23:04), Jan-Peter Seifert wrote: I don't understand why ANSI drivers work. Could you please try the dll on testing for 9.1.0300 at http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/index.html ? regards, Hiroshi Inoue </pre> Hiroshi Inoue 2013-05-15T15:31:45 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9493 <pre>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 </pre> Hiroshi Saito 2013-05-15T14:51:09 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9492 <pre>Sound good to me:-) Many users seem to be waiting for the new release. I'm working on re-confirmation of some. Thanks! (2013/05/15 0:32), ljwilson wrote: </pre> Hiroshi Saito 2013-05-15T14:31:52 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9491 <pre>So the answer to this thread's question is "No", now that Hiroshi Inoue has committed a patch which lets UseDeclareFetch=1 and UseServerSidePrepare=1 co-exist quite happily in my multi-user Windows application with the latest psqlodbc compiled from source. Many thanks again to Inoue-san for the quick turnaround. ...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/Are-UseDeclareFetch-and-UseServerSidePrepare-mutually-exclusive-tp5755080p5755435.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com. </pre> ljwilson 2013-05-14T15:32:00 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9490 <pre> Hello Heikki, sorry - not psqlODBC but our client software was the cause this time. Thank you very much for your quick response! Peter </pre> Jan-Peter Seifert 2013-05-13T16:29:06 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9489 <pre> OK you wrote &gt; 3. With UserDeclareFetch=1 and UseServerSidePrepare=1, the first &gt; workstation that opens the database "wins". Then the second &gt; workstation cannot open the database on its own connection until &gt; the first workstation exits its program. ISTM the second workstation is waiting for the return of a query when the database is blocked to be opened. Could you check it? regards, Hiroshi Inoue </pre> Hiroshi Inoue 2013-05-13T16:26:21 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9488 <pre>Hi Heikki, I opened the service request with Oracle and they solved my problem. It is indeed a bug on the gateway for ODBC. People who have access to Oracle Support can check note 1468941.1 . If I understood correctly, the problem is that the gateway by default does not convert from nchar to char and back. They told me this will be fixed on patchset 11.2.0.4, but in the meantime there is the following workaround to activate this type of conversion: 1. Please get your DG4ODBC class using this select statement executed as sysdba: select fds_class_name from HS_FDS_CLASS; =&gt; you should see a class like: ODBC11.2.0.2.0_0008 2. When you now check out the to_nchar capability you'll see it is turned off (=0) select * from hs_class_caps where upper(CAP_DESCRIPTION) like '%NCHAR%' and FDS_CLASS_NAME ='ODBC11.2.0.2.0_0008'; =&gt; relevant to_char capability is 564: 564 TO_NCHAR(op1) 0 3. We now need to modify this capability and turn it on: exec DBMS_HS.ALTER_CLASS_CAPS('ODBC11.2.0.2.0_0008' , 564, 'ODBC1</pre> Carlos Muñoz Juste 2013-05-13T15:49:57 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9487 <pre>No, just standard select/update statements. I set log_statement = 'ddl' in postgresql.conf and did a reload just to make sure no ddl commands were being executed. Here is a list of the unique sql statements (first few words only) for a test session (extracted with log_statement = 'all'): BEGIN;declare "SQL_CUR05628E20" cursor for SELECT COMMIT INSERT INTO RELEASE _EXEC_SVP_056292B0 SAVEPOINT _EXEC_SVP_056292B0 SELECT UPDATE close "SQL_CUR05628E20";commit declare "SQL_CUR05628E20" cursor with hold for SELECT COUNT(*) FROM delete from Thanks...jack -- View this message in context: http://postgresql.1045698.n5.nabble.com/Are-UseDeclareFetch-and-UseServerSidePrepare-mutually-exclusive-tp5755080p5755243.html Sent from the PostgreSQL - odbc mailing list archive at Nabble.com. </pre> ljwilson 2013-05-13T14:13:22 http://permalink.gmane.org/gmane.comp.db.postgresql.odbc/9486 <pre> 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 ) []{}(),;?*=!&lt; at &gt;  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 </pre> Jan-Peter Seifert 2013-05-13T14:04:57 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.db.postgresql.odbc