Thread: [ODBC] psqlODBC 09.06.0400 Released
Hi, all. We are pleased to annouce the release of psqlODBC 09.06.0400. This is a some bugfix release. please see the notes at: https://odbc.postgresql.org/docs/release.html psqlODBC may be downloaded from in source, Windows Installer, merge module, and basic zip file formats. New Windows installer installs both 32-bit and 64-bit driver at once on 64-bit OS. Both drivers may be needed on 64-bit OS because 32-bit applications require 32-bit driver and 64-bit applications require 64-bit driver. Please post any bug reports to the mailing list. I'd like to take this opportunity to thank all those involved with the development, testing and bug fixing of the updated driver. We are grateful to the help of many peoples. Thanks! -- psqlODBC team. email: pgsql-odbc@postgresql.org website: https://odbc.postgresql.org/
Hi,
Many thanks for the release.
> psqlODBC may be downloaded from in source, Windows Installer, merge module,
> and basic zip file formats.
I have tried to do regression test in Windows environment but it failed with below error.
I think the test\RegisterRegdsn.c file is not included in tar ball.
Or am I missing something?
c1 : fatal error C1083: ソース ファイルを開けません。'..\test\src\..\RegisterRegdsn.c':No such file or directory
[D:\work\source\psqlodbc-09.06.0400\winbuild\regress_one.vcxproj]
Compile error
発生場所 D:\work\source\psqlodbc-09.06.0400\winbuild\regress.ps1:357 文字:3
+ throw "`nCompile error"
+ ~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : OperationStopped: (
Compile error:String) [], RuntimeException
+ FullyQualifiedErrorId :
Compile error
---
Thanks and best regards,
Dang Minh Huong
NEC Solution Innovators, Ltd.
http://www.nec-solutioninnovators.co.jp/en/
Hi Huong, On 2017/07/19 11:18, Huong Dangminh wrote: > Hi, > > Many thanks for the release. > >> psqlODBC may be downloaded from in source, Windows Installer, merge module, >> and basic zip file formats. > I have tried to do regression test in Windows environment but it failed with below error. Hmm, currently the regression test is for developers who keep psqlodbc git tree. Do you build from source and test? > I think the test\RegisterRegdsn.c file is not included in tar ball. > Or am I missing something? > > c1 : fatal error C1083: ソース ファイルを開けません。'..\test\src\..\RegisterRegdsn.c':No such file or directory [D:\work\source\psqlodbc-09.06.0400\winbuild\regress_one.vcxproj] > Compile error > 発生場所 D:\work\source\psqlodbc-09.06.0400\winbuild\regress.ps1:357 文字:3 > + throw "`nCompile error" > + ~~~~~~~~~~~~~~~~~~~~~~~ > + CategoryInfo : OperationStopped: ( > Compile error:String) [], RuntimeException > + FullyQualifiedErrorId : > Compile error > > > --- > Thanks and best regards, > Dang Minh Huong > NEC Solution Innovators, Ltd. > http://www.nec-solutioninnovators.co.jp/en/
Hi Inoue-san, > >> psqlODBC may be downloaded from in source, Windows Installer, merge > >> module, and basic zip file formats. > > I have tried to do regression test in Windows environment but it failed > with below error. > > Hmm, currently the regression test is for developers who keep psqlodbc git > tree. Sorry. I did not know that policy. > Do you build from source and test? Yes I did. So, no problem. I will get it from psqlodbc git, thanks. --- Thanks and best regards, Dang Minh Huong NEC Solution Innovators, Ltd. http://www.nec-solutioninnovators.co.jp/en/
Thanks for the release!
On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote:
> Please post any bug reports to the mailing list.
The testsuite started to fail with 09.06.0400 on Fedora x86_64:
...
cursor-block-delete ........ Dubious, test returned 1 (wstat 256, 0x100)
...
error-rollback ............. Dubious, test returned 1 (wstat 256, 0x100)
...
More info/logs in [1]. I'd be happy to provide more info if needed.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515
Thanks,
Pavel
Hi Pavel,
On 2017/07/19 15:07, Pavel Raiskup wrote:
> Thanks for the release!
>
> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote:
>> Please post any bug reports to the mailing list.
> The testsuite started to fail with 09.06.0400 on Fedora x86_64:
>
> ...
> cursor-block-delete ........ Dubious, test returned 1 (wstat 256, 0x100)
> ...
> error-rollback ............. Dubious, test returned 1 (wstat 256, 0x100)
> ...
>
> More info/logs in [1]. I'd be happy to provide more info if needed.
Thanks for the report.
Could you take mylog for the test case?
After editing the odbc.ini file for the testsuite
DEBUG = 1
and
make installcheck TESTNAMES=cursor-block-delete
Probably you can find mylog files in /tmp dir.
regards,
Hiroshi Inoue
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515
>
> Thanks,
> Pavel
On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: > Hi Pavel, > > On 2017/07/19 15:07, Pavel Raiskup wrote: > > Thanks for the release! > > > > On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: > >> Please post any bug reports to the mailing list. > > The testsuite started to fail with 09.06.0400 on Fedora x86_64: > > > > ... > > cursor-block-delete ........ Dubious, test returned 1 (wstat 256, 0x100) > > ... > > error-rollback ............. Dubious, test returned 1 (wstat 256, 0x100) > > ... > > > > More info/logs in [1]. I'd be happy to provide more info if needed. > > Could you take mylog for the test case? > > After editing the odbc.ini file for the testsuite > DEBUG = 1 > and > make installcheck TESTNAMES=cursor-block-delete > > Probably you can find mylog files in /tmp dir. The log is here: [140271643534336] start_logging:Global.debug&commlog=1&0 [140271643534336][[SQLAllocHandle]][140271643534336]**** in PGAPI_AllocEnv ** [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** [140271643534336][[SQLSetEnvAttr]] att=200,3 [140271643534336][[SQLGetEnvAttr]] 200 [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: entering... [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn = 0x5641633c7740 [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = 0x5641633c7740 [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, conns[0]->henv = 0x5641633cc0b0 [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: entering... [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' [140271643534336]CC_conninfo_init opt=2 [140271643534336]our_connect_string = 'DSN=psqlodbc_test_dsn;Database=postgres' [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) [140271643534336]calling getCiDefaults [140271643534336]drivername=PostgreSQL Unicode [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver PostgreSQL Unicode [140271643534336]comval=0x5641633c7fb8 comval->extra_systable_prefixes = '' [140271643534336]get_Ci_Drivers:setting .odbc.ini position of psqlodbc_test_dsn(0x5641633c7fb8) [140271643534336]comval=0x5641633c7fb8 comval->extra_systable_prefixes = '' [140271643534336]our_connect_string = 'DSN=psqlodbc_test_dsn;Database=postgres' [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' [140271643534336]copyConnAttributes: key='Database' value='postgres' Pavel > regards, > Hiroshi Inoue > > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 > > > > Thanks, > > Pavel >
Hi, On 2017/07/19 19:29, Pavel Raiskup wrote: > On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: >> Hi Pavel, >> >> On 2017/07/19 15:07, Pavel Raiskup wrote: >>> Thanks for the release! >>> >>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: >>>> Please post any bug reports to the mailing list. >>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: >>> >>> ... >>> cursor-block-delete ........ Dubious, test returned 1 (wstat 256, 0x100) >>> ... >>> error-rollback ............. Dubious, test returned 1 (wstat 256, 0x100) >>> ... >>> >>> More info/logs in [1]. I'd be happy to provide more info if needed. >> Could you take mylog for the test case? >> >> After editing the odbc.ini file for the testsuite >> DEBUG = 1 >> and >> make installcheck TESTNAMES=cursor-block-delete >> >> Probably you can find mylog files in /tmp dir. > The log is here: Thanks. Aren't you turning on DEBUG of odbcinst.ini file? Please turn on DEBUG of odbc.ini file also. regrards, Hiroshi Inoue > > [140271643534336] start_logging:Global.debug&commlog=1&0 > [140271643534336][[SQLAllocHandle]][140271643534336]**** in PGAPI_AllocEnv ** > [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** > [140271643534336][[SQLSetEnvAttr]] att=200,3 > [140271643534336][[SQLGetEnvAttr]] 200 > [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: entering... > [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn = 0x5641633c7740 > [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = 0x5641633c7740 > [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, conns[0]->henv = 0x5641633cc0b0 > [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: entering... > [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' > [140271643534336]CC_conninfo_init opt=2 > [140271643534336]our_connect_string = 'DSN=psqlodbc_test_dsn;Database=postgres' > [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) > [140271643534336]calling getCiDefaults > [140271643534336]drivername=PostgreSQL Unicode > [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver PostgreSQL Unicode > [140271643534336]comval=0x5641633c7fb8 comval->extra_systable_prefixes = '' > [140271643534336]get_Ci_Drivers:setting .odbc.ini position of psqlodbc_test_dsn(0x5641633c7fb8) > [140271643534336]comval=0x5641633c7fb8 comval->extra_systable_prefixes = '' > [140271643534336]our_connect_string = 'DSN=psqlodbc_test_dsn;Database=postgres' > [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' > [140271643534336]copyConnAttributes: key='Database' value='postgres' > > Pavel > > >> regards, >> Hiroshi Inoue >> >>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 >>> >>> Thanks, >>> Pavel
Hi Pavel, Could you try the attached patch? regards, Hiroshi Inoue On 2017/07/19 20:26, Inoue, Hiroshi wrote: > Hi, > > On 2017/07/19 19:29, Pavel Raiskup wrote: >> On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: >>> Hi Pavel, >>> >>> On 2017/07/19 15:07, Pavel Raiskup wrote: >>>> Thanks for the release! >>>> >>>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: >>>>> Please post any bug reports to the mailing list. >>>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: >>>> >>>> ... >>>> cursor-block-delete ........ Dubious, test returned 1 (wstat >>>> 256, 0x100) >>>> ... >>>> error-rollback ............. Dubious, test returned 1 (wstat >>>> 256, 0x100) >>>> ... >>>> >>>> More info/logs in [1]. I'd be happy to provide more info if needed. >>> Could you take mylog for the test case? >>> >>> After editing the odbc.ini file for the testsuite >>> DEBUG = 1 >>> and >>> make installcheck TESTNAMES=cursor-block-delete >>> >>> Probably you can find mylog files in /tmp dir. >> The log is here: > > Thanks. > Aren't you turning on DEBUG of odbcinst.ini file? > Please turn on DEBUG of odbc.ini file also. > > regrards, > Hiroshi Inoue > >> >> [140271643534336] start_logging:Global.debug&commlog=1&0 >> [140271643534336][[SQLAllocHandle]][140271643534336]**** in >> PGAPI_AllocEnv ** >> [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** >> [140271643534336][[SQLSetEnvAttr]] att=200,3 >> [140271643534336][[SQLGetEnvAttr]] 200 >> [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: >> entering... >> [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn >> = 0x5641633c7740 >> [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = >> 0x5641633c7740 >> [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, >> conns[0]->henv = 0x5641633cc0b0 >> [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: >> entering... >> [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, >> connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' >> [140271643534336]CC_conninfo_init opt=2 >> [140271643534336]our_connect_string = >> 'DSN=psqlodbc_test_dsn;Database=postgres' >> [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) >> [140271643534336]calling getCiDefaults >> [140271643534336]drivername=PostgreSQL Unicode >> [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver >> PostgreSQL Unicode >> [140271643534336]comval=0x5641633c7fb8 >> comval->extra_systable_prefixes = '' >> [140271643534336]get_Ci_Drivers:setting .odbc.ini position of >> psqlodbc_test_dsn(0x5641633c7fb8) >> [140271643534336]comval=0x5641633c7fb8 >> comval->extra_systable_prefixes = '' >> [140271643534336]our_connect_string = >> 'DSN=psqlodbc_test_dsn;Database=postgres' >> [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' >> [140271643534336]copyConnAttributes: key='Database' value='postgres' >> >> Pavel >> >> >>> regards, >>> Hiroshi Inoue >>> >>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 >>>> >>>> Thanks, >>>> Pavel
Attachment
On Wednesday, July 19, 2017 2:03:48 PM CEST Inoue, Hiroshi wrote: > Hi Pavel, > > Could you try the attached patch? The patch did not help (after quick check, I hope I've tested it correctly), I'm attaching two logs which appeared in /tmp (as you requested before). Pavel > regards, > Hiroshi Inoue > > On 2017/07/19 20:26, Inoue, Hiroshi wrote: > > Hi, > > > > On 2017/07/19 19:29, Pavel Raiskup wrote: > >> On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: > >>> Hi Pavel, > >>> > >>> On 2017/07/19 15:07, Pavel Raiskup wrote: > >>>> Thanks for the release! > >>>> > >>>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: > >>>>> Please post any bug reports to the mailing list. > >>>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: > >>>> > >>>> ... > >>>> cursor-block-delete ........ Dubious, test returned 1 (wstat > >>>> 256, 0x100) > >>>> ... > >>>> error-rollback ............. Dubious, test returned 1 (wstat > >>>> 256, 0x100) > >>>> ... > >>>> > >>>> More info/logs in [1]. I'd be happy to provide more info if needed. > >>> Could you take mylog for the test case? > >>> > >>> After editing the odbc.ini file for the testsuite > >>> DEBUG = 1 > >>> and > >>> make installcheck TESTNAMES=cursor-block-delete > >>> > >>> Probably you can find mylog files in /tmp dir. > >> The log is here: > > > > Thanks. > > Aren't you turning on DEBUG of odbcinst.ini file? > > Please turn on DEBUG of odbc.ini file also. > > > > regrards, > > Hiroshi Inoue > > > >> > >> [140271643534336] start_logging:Global.debug&commlog=1&0 > >> [140271643534336][[SQLAllocHandle]][140271643534336]**** in > >> PGAPI_AllocEnv ** > >> [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** > >> [140271643534336][[SQLSetEnvAttr]] att=200,3 > >> [140271643534336][[SQLGetEnvAttr]] 200 > >> [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: > >> entering... > >> [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn > >> = 0x5641633c7740 > >> [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = > >> 0x5641633c7740 > >> [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, > >> conns[0]->henv = 0x5641633cc0b0 > >> [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: > >> entering... > >> [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, > >> connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' > >> [140271643534336]CC_conninfo_init opt=2 > >> [140271643534336]our_connect_string = > >> 'DSN=psqlodbc_test_dsn;Database=postgres' > >> [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) > >> [140271643534336]calling getCiDefaults > >> [140271643534336]drivername=PostgreSQL Unicode > >> [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver > >> PostgreSQL Unicode > >> [140271643534336]comval=0x5641633c7fb8 > >> comval->extra_systable_prefixes = '' > >> [140271643534336]get_Ci_Drivers:setting .odbc.ini position of > >> psqlodbc_test_dsn(0x5641633c7fb8) > >> [140271643534336]comval=0x5641633c7fb8 > >> comval->extra_systable_prefixes = '' > >> [140271643534336]our_connect_string = > >> 'DSN=psqlodbc_test_dsn;Database=postgres' > >> [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' > >> [140271643534336]copyConnAttributes: key='Database' value='postgres' > >> > >> Pavel > >> > >> > >>> regards, > >>> Hiroshi Inoue > >>> > >>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 > >>>> > >>>> Thanks, > >>>> Pavel >
Attachment
Hi, On 2017/07/19 22:07, Pavel Raiskup wrote: > On Wednesday, July 19, 2017 2:03:48 PM CEST Inoue, Hiroshi wrote: >> Hi Pavel, >> >> Could you try the attached patch? > The patch did not help (after quick check, I hope I've tested it correctly), I'm > attaching two logs which appeared in /tmp (as you requested before). Thanks. Could you try the attached patch? regards, Hiroshi Inoue > Pavel > >> regards, >> Hiroshi Inoue >> >> On 2017/07/19 20:26, Inoue, Hiroshi wrote: >>> Hi, >>> >>> On 2017/07/19 19:29, Pavel Raiskup wrote: >>>> On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: >>>>> Hi Pavel, >>>>> >>>>> On 2017/07/19 15:07, Pavel Raiskup wrote: >>>>>> Thanks for the release! >>>>>> >>>>>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: >>>>>>> Please post any bug reports to the mailing list. >>>>>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: >>>>>> >>>>>> ... >>>>>> cursor-block-delete ........ Dubious, test returned 1 (wstat >>>>>> 256, 0x100) >>>>>> ... >>>>>> error-rollback ............. Dubious, test returned 1 (wstat >>>>>> 256, 0x100) >>>>>> ... >>>>>> >>>>>> More info/logs in [1]. I'd be happy to provide more info if needed. >>>>> Could you take mylog for the test case? >>>>> >>>>> After editing the odbc.ini file for the testsuite >>>>> DEBUG = 1 >>>>> and >>>>> make installcheck TESTNAMES=cursor-block-delete >>>>> >>>>> Probably you can find mylog files in /tmp dir. >>>> The log is here: >>> Thanks. >>> Aren't you turning on DEBUG of odbcinst.ini file? >>> Please turn on DEBUG of odbc.ini file also. >>> >>> regrards, >>> Hiroshi Inoue >>> >>>> [140271643534336] start_logging:Global.debug&commlog=1&0 >>>> [140271643534336][[SQLAllocHandle]][140271643534336]**** in >>>> PGAPI_AllocEnv ** >>>> [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** >>>> [140271643534336][[SQLSetEnvAttr]] att=200,3 >>>> [140271643534336][[SQLGetEnvAttr]] 200 >>>> [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: >>>> entering... >>>> [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn >>>> = 0x5641633c7740 >>>> [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = >>>> 0x5641633c7740 >>>> [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, >>>> conns[0]->henv = 0x5641633cc0b0 >>>> [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: >>>> entering... >>>> [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, >>>> connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' >>>> [140271643534336]CC_conninfo_init opt=2 >>>> [140271643534336]our_connect_string = >>>> 'DSN=psqlodbc_test_dsn;Database=postgres' >>>> [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) >>>> [140271643534336]calling getCiDefaults >>>> [140271643534336]drivername=PostgreSQL Unicode >>>> [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver >>>> PostgreSQL Unicode >>>> [140271643534336]comval=0x5641633c7fb8 >>>> comval->extra_systable_prefixes = '' >>>> [140271643534336]get_Ci_Drivers:setting .odbc.ini position of >>>> psqlodbc_test_dsn(0x5641633c7fb8) >>>> [140271643534336]comval=0x5641633c7fb8 >>>> comval->extra_systable_prefixes = '' >>>> [140271643534336]our_connect_string = >>>> 'DSN=psqlodbc_test_dsn;Database=postgres' >>>> [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' >>>> [140271643534336]copyConnAttributes: key='Database' value='postgres' >>>> >>>> Pavel >>>> >>>> >>>>> regards, >>>>> Hiroshi Inoue >>>>> >>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 >>>>>> >>>>>> Thanks, >>>>>> Pavel
Attachment
On Wednesday, July 19, 2017 4:15:22 PM CEST Inoue, Hiroshi wrote: > Hi, > > On 2017/07/19 22:07, Pavel Raiskup wrote: > > On Wednesday, July 19, 2017 2:03:48 PM CEST Inoue, Hiroshi wrote: > >> Hi Pavel, > >> > >> Could you try the attached patch? > > The patch did not help (after quick check, I hope I've tested it correctly), I'm > > attaching two logs which appeared in /tmp (as you requested before). > > Thanks. > Could you try the attached patch? This one works fine for me [1], thanks! [1] https://copr.fedorainfracloud.org/coprs/praiskup/test-rhbz-1472515/builds/ Pavel > regards, > Hiroshi Inoue > > > Pavel > > > >> regards, > >> Hiroshi Inoue > >> > >> On 2017/07/19 20:26, Inoue, Hiroshi wrote: > >>> Hi, > >>> > >>> On 2017/07/19 19:29, Pavel Raiskup wrote: > >>>> On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: > >>>>> Hi Pavel, > >>>>> > >>>>> On 2017/07/19 15:07, Pavel Raiskup wrote: > >>>>>> Thanks for the release! > >>>>>> > >>>>>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: > >>>>>>> Please post any bug reports to the mailing list. > >>>>>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: > >>>>>> > >>>>>> ... > >>>>>> cursor-block-delete ........ Dubious, test returned 1 (wstat > >>>>>> 256, 0x100) > >>>>>> ... > >>>>>> error-rollback ............. Dubious, test returned 1 (wstat > >>>>>> 256, 0x100) > >>>>>> ... > >>>>>> > >>>>>> More info/logs in [1]. I'd be happy to provide more info if needed. > >>>>> Could you take mylog for the test case? > >>>>> > >>>>> After editing the odbc.ini file for the testsuite > >>>>> DEBUG = 1 > >>>>> and > >>>>> make installcheck TESTNAMES=cursor-block-delete > >>>>> > >>>>> Probably you can find mylog files in /tmp dir. > >>>> The log is here: > >>> Thanks. > >>> Aren't you turning on DEBUG of odbcinst.ini file? > >>> Please turn on DEBUG of odbc.ini file also. > >>> > >>> regrards, > >>> Hiroshi Inoue > >>> > >>>> [140271643534336] start_logging:Global.debug&commlog=1&0 > >>>> [140271643534336][[SQLAllocHandle]][140271643534336]**** in > >>>> PGAPI_AllocEnv ** > >>>> [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** > >>>> [140271643534336][[SQLSetEnvAttr]] att=200,3 > >>>> [140271643534336][[SQLGetEnvAttr]] 200 > >>>> [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: > >>>> entering... > >>>> [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn > >>>> = 0x5641633c7740 > >>>> [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = > >>>> 0x5641633c7740 > >>>> [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, > >>>> conns[0]->henv = 0x5641633cc0b0 > >>>> [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: > >>>> entering... > >>>> [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, > >>>> connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' > >>>> [140271643534336]CC_conninfo_init opt=2 > >>>> [140271643534336]our_connect_string = > >>>> 'DSN=psqlodbc_test_dsn;Database=postgres' > >>>> [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) > >>>> [140271643534336]calling getCiDefaults > >>>> [140271643534336]drivername=PostgreSQL Unicode > >>>> [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver > >>>> PostgreSQL Unicode > >>>> [140271643534336]comval=0x5641633c7fb8 > >>>> comval->extra_systable_prefixes = '' > >>>> [140271643534336]get_Ci_Drivers:setting .odbc.ini position of > >>>> psqlodbc_test_dsn(0x5641633c7fb8) > >>>> [140271643534336]comval=0x5641633c7fb8 > >>>> comval->extra_systable_prefixes = '' > >>>> [140271643534336]our_connect_string = > >>>> 'DSN=psqlodbc_test_dsn;Database=postgres' > >>>> [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' > >>>> [140271643534336]copyConnAttributes: key='Database' value='postgres' > >>>> > >>>> Pavel > >>>> > >>>> > >>>>> regards, > >>>>> Hiroshi Inoue > >>>>> > >>>>>> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1472515 > >>>>>> > >>>>>> Thanks, > >>>>>> Pavel >
Hi Pavel, On 2017/07/20 0:00, Pavel Raiskup wrote: > On Wednesday, July 19, 2017 4:15:22 PM CEST Inoue, Hiroshi wrote: >> Hi, >> >> On 2017/07/19 22:07, Pavel Raiskup wrote: >>> On Wednesday, July 19, 2017 2:03:48 PM CEST Inoue, Hiroshi wrote: >>>> Hi Pavel, >>>> >>>> Could you try the attached patch? >>> The patch did not help (after quick check, I hope I've tested it correctly), I'm >>> attaching two logs which appeared in /tmp (as you requested before). >> Thanks. >> Could you try the attached patch? > This one works fine for me [1], thanks! Great thanks for your verification. We would make a new release for the bug fix. regards, Hiroshi Inoue > [1]https://copr.fedorainfracloud.org/coprs/praiskup/test-rhbz-1472515/builds/ > > Pavel > >> regards, >> Hiroshi Inoue >> >>> Pavel >>> >>>> regards, >>>> Hiroshi Inoue >>>> >>>> On 2017/07/19 20:26, Inoue, Hiroshi wrote: >>>>> Hi, >>>>> >>>>> On 2017/07/19 19:29, Pavel Raiskup wrote: >>>>>> On Wednesday, July 19, 2017 10:31:33 AM CEST Inoue, Hiroshi wrote: >>>>>>> Hi Pavel, >>>>>>> >>>>>>> On 2017/07/19 15:07, Pavel Raiskup wrote: >>>>>>>> Thanks for the release! >>>>>>>> >>>>>>>> On Tuesday, July 18, 2017 4:46:58 PM CEST Hiroshi Saito wrote: >>>>>>>>> Please post any bug reports to the mailing list. >>>>>>>> The testsuite started to fail with 09.06.0400 on Fedora x86_64: >>>>>>>> >>>>>>>> ... >>>>>>>> cursor-block-delete ........ Dubious, test returned 1 (wstat >>>>>>>> 256, 0x100) >>>>>>>> ... >>>>>>>> error-rollback ............. Dubious, test returned 1 (wstat >>>>>>>> 256, 0x100) >>>>>>>> ... >>>>>>>> >>>>>>>> More info/logs in [1]. I'd be happy to provide more info if needed. >>>>>>> Could you take mylog for the test case? >>>>>>> >>>>>>> After editing the odbc.ini file for the testsuite >>>>>>> DEBUG = 1 >>>>>>> and >>>>>>> make installcheck TESTNAMES=cursor-block-delete >>>>>>> >>>>>>> Probably you can find mylog files in /tmp dir. >>>>>> The log is here: >>>>> Thanks. >>>>> Aren't you turning on DEBUG of odbcinst.ini file? >>>>> Please turn on DEBUG of odbc.ini file also. >>>>> >>>>> regrards, >>>>> Hiroshi Inoue >>>>> >>>>>> [140271643534336] start_logging:Global.debug&commlog=1&0 >>>>>> [140271643534336][[SQLAllocHandle]][140271643534336]**** in >>>>>> PGAPI_AllocEnv ** >>>>>> [140271643534336]** exit PGAPI_AllocEnv: phenv = 0x5641633cc0b0 ** >>>>>> [140271643534336][[SQLSetEnvAttr]] att=200,3 >>>>>> [140271643534336][[SQLGetEnvAttr]] 200 >>>>>> [140271643534336][[SQLAllocHandle]][140271643534336]PGAPI_AllocConnect: >>>>>> entering... >>>>>> [140271643534336]**** PGAPI_AllocConnect: henv = 0x5641633cc0b0, conn >>>>>> = 0x5641633c7740 >>>>>> [140271643534336]EN_add_connection: self = 0x5641633cc0b0, conn = >>>>>> 0x5641633c7740 >>>>>> [140271643534336] added at 0, conn->henv = 0x5641633cc0b0, >>>>>> conns[0]->henv = 0x5641633cc0b0 >>>>>> [140271643534336][SQLDriverConnect][140271643534336]PGAPI_DriverConnect: >>>>>> entering... >>>>>> [140271643534336]**** PGAPI_DriverConnect: fDriverCompletion=0, >>>>>> connStrIn='DSN=psqlodbc_test_dsn;Database=postgres' >>>>>> [140271643534336]CC_conninfo_init opt=2 >>>>>> [140271643534336]our_connect_string = >>>>>> 'DSN=psqlodbc_test_dsn;Database=postgres' >>>>>> [140271643534336]getDSNinfo: DSN=psqlodbc_test_dsn driver=&(null) >>>>>> [140271643534336]calling getCiDefaults >>>>>> [140271643534336]drivername=PostgreSQL Unicode >>>>>> [140271643534336]getDriversDefaults:0x5641633c7fb8 of the driver >>>>>> PostgreSQL Unicode >>>>>> [140271643534336]comval=0x5641633c7fb8 >>>>>> comval->extra_systable_prefixes = '' >>>>>> [140271643534336]get_Ci_Drivers:setting .odbc.ini position of >>>>>> psqlodbc_test_dsn(0x5641633c7fb8) >>>>>> [140271643534336]comval=0x5641633c7fb8 >>>>>> comval->extra_systable_prefixes = '' >>>>>> [140271643534336]our_connect_string = >>>>>> 'DSN=psqlodbc_test_dsn;Database=postgres' >>>>>> [140271643534336]copyConnAttributes: key='DSN' value='psqlodbc_test_dsn' >>>>>> [140271643534336]copyConnAttributes: key='Database' value='postgres' >>>>>> >>>>>> Pavel >>>>>> >>>>>> >>>>>>> regards, >>>>>>> Hiroshi Inoue >>>>>>> >>>>>>>> [1]https://bugzilla.redhat.com/show_bug.cgi?id=1472515 >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Pavel
* Hiroshi Saito wrote: > We are pleased to annouce the release of psqlODBC 09.06.0400. Hello, this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for some tables the data looks good, some are entirely filled with "#Deleted". Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically, there are always nine rows like that, followed by one with valid data. If I change the sort order of any column, I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted". Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first page is still similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. if the window does not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before. I have switched back and forth between .310 and .400 a few times, with reproducible results each time. There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Access likes timestamp columns for identifying rows; none of my tables have any. The behavior is the same with default data source options and with these nondefault options: - "Row Versioning" enabled - "True is -1" enabled - "Bools as Char" disabled In my experience, these settings are necessary for Access to work at all. Screenshot attached. -- Christian
Attachment
Hello We are also encountering issues when using psqlODBC 09.06.0400 with MSACCESS 2016, it seems to lose the connection to thedatabase. I can open forms, but get issues with some data not showing, similar to Christian but mine shows "#Name?" ratherthan "#Deleted" . If I try and look at a table via MSACCESS sometimes I can see the data, other times I get an "ODBC -- call failed" error. Even though I have debug enabled I get no log files generated. Everything works fine when we use psqlODBC 09.06.0310 Regards Robert Ball Manifest Tel: +44 (0)1376 504511 | Main: +44 (0)1376 503500 | Fax: +44 (0)1376 503550 Blog: https://blog.manifest.co.uk/ | Web: https://www.manifest.co.uk/ 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | England ---------------------------------------------------------------------------------------------------------------------------- Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee youmust not use or disclose such information, instead please report it to admin@manifest.co.uk. Legal: Manifest is the trading name of: Manifest Information Services Ltd: Registered in England Number 3401145 & The ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/for further information. -----Original Message----- From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Christian Ullrich Sent: 20 July 2017 15:08 To: pgsql-odbc@postgresql.org Subject: Re: [ODBC] psqlODBC 09.06.0400 Released * Hiroshi Saito wrote: > We are pleased to annouce the release of psqlODBC 09.06.0400. Hello, this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for sometables the data looks good, some are entirely filled with "#Deleted". Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically,there are always nine rows like that, followed by one with valid data. If I change the sort order of any column,I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted". Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first page isstill similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. if the windowdoes not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before. I have switched back and forth between .310 and .400 a few times, with reproducible results each time. There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Accesslikes timestamp columns for identifying rows; none of my tables have any. The behavior is the same with default data source options and with these nondefault options: - "Row Versioning" enabled - "True is -1" enabled - "Bools as Char" disabled In my experience, these settings are necessary for Access to work at all. Screenshot attached. -- Christian
Hi Christian, Thanks for the report. It would take some time for me to examine it. regards, Hiroshi Inoue On 2017/07/20 23:07, Christian Ullrich wrote: > * Hiroshi Saito wrote: > >> We are pleased to annouce the release of psqlODBC 09.06.0400. > > Hello, > > this release changes the behavior of linked tables in MS Access 2016 > (x86). With 9.6.310, all is well, with .400, for some tables the data > looks good, some are entirely filled with "#Deleted". > > Most interestingly, however, for some tables, exactly 9 out of every > 10 rows in datasheet view are "#Deleted". Specifically, there are > always nine rows like that, followed by one with valid data. If I > change the sort order of any column, I get a screenful of valid rows, > except for the selected row; that one stays at "#Deleted". > > Changing sort order always jumps the view back up to the first row; > when I scroll down, everything below the first page is still similar > to before; nine rows #Deleted, one row valid, repeat. The pattern > resumes at the page edge, i.e. if the window does not show a multiple > of 10 rows the valid rows after scrolling down will be different ones > than before. > > I have switched back and forth between .310 and .400 a few times, with > reproducible results each time. > > There is no apparent correlation between .400's behavior for any given > table and the content of that table. ISTR that Access likes timestamp > columns for identifying rows; none of my tables have any. > > The behavior is the same with default data source options and with > these nondefault options: > > - "Row Versioning" enabled > - "True is -1" enabled > - "Bools as Char" disabled > > In my experience, these settings are necessary for Access to work at all. > > Screenshot attached
Hi Robert, On 2017/07/20 23:19, Robert Ball wrote: > Hello > > We are also encountering issues when using psqlODBC 09.06.0400 with MSACCESS 2016, it seems to lose the connection to thedatabase. I can open forms, but get issues with some data not showing, similar to Christian but mine shows "#Name?" ratherthan "#Deleted" . > > If I try and look at a table via MSACCESS sometimes I can see the data, other times I get an "ODBC -- call failed" error. Thanks for the report. > > > Even though I have debug enabled I get no log files generated. Do you turn on the global debug option? regards, Hiroshi Inoue > > Everything works fine when we use psqlODBC 09.06.0310 > > Regards > Robert Ball > > Manifest > > Tel: +44 (0)1376 504511 | Main: +44 (0)1376 503500 | Fax: +44 (0)1376 503550 > > Blog: https://blog.manifest.co.uk/ | Web: https://www.manifest.co.uk/ > > 9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | England > > ---------------------------------------------------------------------------------------------------------------------------- > > Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee youmust not use or disclose such information, instead please report it to admin@manifest.co.uk. > Legal: Manifest is the trading name of: Manifest Information Services Ltd: Registered in England Number 3401145 & The ManifestVoting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/for further information. > > -----Original Message----- > From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Christian Ullrich > Sent: 20 July 2017 15:08 > To: pgsql-odbc@postgresql.org > Subject: Re: [ODBC] psqlODBC 09.06.0400 Released > > * Hiroshi Saito wrote: > >> We are pleased to annouce the release of psqlODBC 09.06.0400. > Hello, > > this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for sometables the data looks good, some are entirely filled with "#Deleted". > > Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically,there are always nine rows like that, followed by one with valid data. If I change the sort order of any column,I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted". > > Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first pageis still similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. ifthe window does not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before. > > I have switched back and forth between .310 and .400 a few times, with reproducible results each time. > > There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Accesslikes timestamp columns for identifying rows; none of my tables have any. > > The behavior is the same with default data source options and with these nondefault options: > > - "Row Versioning" enabled > - "True is -1" enabled > - "Bools as Char" disabled > > In my experience, these settings are necessary for Access to work at all. > > Screenshot attached. > > -- > Christian
Hi Christian,
Could you please try the test drivers 9.6.0401 at
http://www.ne.jp/asahi/inocchi
?
regards,
Hiroshi Inoue
On 2017/07/21 16:28, Inoue, Hiroshi wrote:
Hi Christian,
Thanks for the report.
It would take some time for me to examine it.
Could you please try the test drivers 9.6.0401 at
http://www.ne.jp/asahi/inocchi
?
regards,
Hiroshi Inoue
regards,
Hiroshi Inoue
On 2017/07/20 23:07, Christian Ullrich wrote:* Hiroshi Saito wrote:We are pleased to annouce the release of psqlODBC 09.06.0400.
Hello,
this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for some tables the data looks good, some are entirely filled with "#Deleted".
Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically, there are always nine rows like that, followed by one with valid data. If I change the sort order of any column, I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted".
Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first page is still similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. if the window does not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before.
I have switched back and forth between .310 and .400 a few times, with reproducible results each time.
There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Access likes timestamp columns for identifying rows; none of my tables have any.
The behavior is the same with default data source options and with these nondefault options:
- "Row Versioning" enabled
- "True is -1" enabled
- "Bools as Char" disabled
In my experience, these settings are necessary for Access to work at all.
Screenshot attached
Hi Robert,
Could you please try the test drivers 9.6.0401 at
http://www.ne.jp/asahi/inocchi
?
regards,
Hiroshi Inoue
Could you please try the test drivers 9.6.0401 at
http://www.ne.jp/asahi/inocchi
?
regards,
Hiroshi Inoue
On 2017/07/21 16:36, Inoue, Hiroshi wrote:
Hi Robert,
On 2017/07/20 23:19, Robert Ball wrote:Hello
We are also encountering issues when using psqlODBC 09.06.0400 with MSACCESS 2016, it seems to lose the connection to the database. I can open forms, but get issues with some data not showing, similar to Christian but mine shows "#Name?" rather than "#Deleted" .
If I try and look at a table via MSACCESS sometimes I can see the data, other times I get an "ODBC -- call failed" error.
Thanks for the report.
Even though I have debug enabled I get no log files generated.
Do you turn on the global debug option?
regards,
Hiroshi Inoue
Everything works fine when we use psqlODBC 09.06.0310
Regards
Robert Ball
Manifest
Tel: +44 (0)1376 504511 | Main: +44 (0)1376 503500 | Fax: +44 (0)1376 503550
Blog: https://blog.manifest.co.uk/ | Web: https://www.manifest.co.uk/
9 Freebournes Court | Newland Street | Witham | Essex | CM8 2BL | England
----------------------------------------------------------------------------------------------------------------------------
Copyright: This e-mail may contain confidential or legally privileged information. If you are not the named addressee you must not use or disclose such information, instead please report it to admin@manifest.co.uk.
Legal: Manifest is the trading name of: Manifest Information Services Ltd: Registered in England Number 3401145 & The Manifest Voting Agency Ltd: Registered in England Number 2920820 Registered Office at above address. Please Click Here https://www.manifest.co.uk/legal/ for further information.
-----Original Message-----
From: pgsql-odbc-owner@postgresql.org [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Christian Ullrich
Sent: 20 July 2017 15:08
To: pgsql-odbc@postgresql.org
Subject: Re: [ODBC] psqlODBC 09.06.0400 Released
* Hiroshi Saito wrote:We are pleased to annouce the release of psqlODBC 09.06.0400.Hello,
this release changes the behavior of linked tables in MS Access 2016 (x86). With 9.6.310, all is well, with .400, for some tables the data looks good, some are entirely filled with "#Deleted".
Most interestingly, however, for some tables, exactly 9 out of every 10 rows in datasheet view are "#Deleted". Specifically, there are always nine rows like that, followed by one with valid data. If I change the sort order of any column, I get a screenful of valid rows, except for the selected row; that one stays at "#Deleted".
Changing sort order always jumps the view back up to the first row; when I scroll down, everything below the first page is still similar to before; nine rows #Deleted, one row valid, repeat. The pattern resumes at the page edge, i.e. if the window does not show a multiple of 10 rows the valid rows after scrolling down will be different ones than before.
I have switched back and forth between .310 and .400 a few times, with reproducible results each time.
There is no apparent correlation between .400's behavior for any given table and the content of that table. ISTR that Access likes timestamp columns for identifying rows; none of my tables have any.
The behavior is the same with default data source options and with these nondefault options:
- "Row Versioning" enabled
- "True is -1" enabled
- "Bools as Char" disabled
In my experience, these settings are necessary for Access to work at all.
Screenshot attached.
--
Christian
* Inoue, Hiroshi wrote: > Could you please try the test drivers 9.6.0401 at > http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/ That looks much better. All tables are complete. Thanks! -- Christian