Thread: New 9.5.0100 does not work properly

On 01/11/2016 06:26 AM, Walter Willmertinger wrote:
> I installed the new version. Normal connection test was OK, but not the
> special connection test in "Page 3".
>
> Using a postgresql database (8.4.22) with MS Access 2013 seemed to work,
> but only read access. As soon as I try to change some data, I get the
> message "Another user has changed ...".
> I uninstalled the new version and installed the last release, now it is
> working again.

When you ran the new version did you see if Row Versioning was checked?

>
> Regards, Walter
> --
>
> Viele Grüße
>
> Walter Willmertinger
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 01/12/2016 12:36 AM, Walter Willmertinger wrote:

Ccing list, so more eyes can see this.

> The "Write Conflict" is independent of the setting "row versioning".
> When I strted it was switched off. I switched to "On", but the same result.

What did you do in between?

In other words did you disconnect/reconnect from the database, log
out/log in, rboot, etc?

I have had issues with ODBC not catching changes to its conf, especially
when there is a live connection.

>
> _Here is an excerpt from mylog:_
>
> /[7.065]conn=000001F55B153090, query='SELECT
>
"KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr"
> FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND "KdID" = 83'
> [8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE
> "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" =
> $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND
> "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND
> "ProgErledigt" = $8 AND "update_cs" = $9 AND
> "ZuletztBearbeitetPersonalNr" IS NULL
> [8.456]conn=000001F55B153090, query='BEGIN'
> [8.457]ParseWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET
> "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" =
> $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND
> "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND
> "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
> [8.460]conn=000001F55B153090, query='UPDATE "public"."Notizen" SET
> "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND "KdID" = 83 AND
> "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND
> "AufnahmeDurchPersonalNr" = 80 AND "WeiterAnPersonalNr" = 80 AND
> "Status" = E'E' AND "Prioritaet" IS NULL AND "ProgErledigt" = E'0' AND
> "update_cs" = E'2015-09-30 13:48:15'::timestamp AND
> "ZuletztBearbeitetPersonalNr" IS NULL'
> [8.464]conn=000001F55B153090, query='ROLLBACK'/

On the face of it the above looks alright. I have seen issues such as
you describe with Access and Postgres when using fractional second
timestamps, but the above uses integer seconds.

>
> _Here is my "ODBC.INI":_
> /[ODBC 32 bit Data Sources]/
> /PgSQL_CONSYS=PostgreSQL ANSI(x64) (32 bit)
> /
> /[PgSQL_CONSYS]
> /
> /Driver32=C:\Program Files\psqlODBC\0903\bin\psqlodbc30a.dll/
>
> *But it's Access 2013 64-bit!*

How did you install psqlodbc and from what source?

Also what OS and version are you running  on?

I do not fully understand the 32/64 bit thing in Windows, so I will
point you at this:

https://odbc.postgresql.org/faq.html#6.8

>
> _Here my registry settings for this ODBC-Entry:_
>
> /[HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\PgSQL_CONSYS]/
> /"Driver"="C:\\Program Files\\psqlODBC\\0903\\bin\\psqlodbc30a.dll"/
> /"CommLog"="1"/
> /"Debug"="0"/
> /"Fetch"="100"/
> /"Optimizer"="0"/
> /"Ksqo"="1"/
> /"UniqueIndex"="1"/
> /"UseDeclareFetch"="0"/
> /"UnknownSizes"="0"/
> /"TextAsLongVarchar"="1"/
> /"UnknownsAsLongVarchar"="0"/
> /"BoolsAsChar"="1"/
> /"Parse"="0"/
> /"CancelAsFreeStmt"="0"/
> /"MaxVarcharSize"="255"/
> /"MaxLongVarcharSize"="8190"/
> /"ExtraSysTablePrefixes"="dd_;"/
> /"Description"="Access 64 Bit"/
> /"Database"="consys"/
> /"Servername"="col"/
> /"Port"="5445"/
> /"Username"="XXXXX"/
> /"UID"="YYYYY"/
> /"Password"="ZZZZZZ"/
> /"ReadOnly"="0"/
> /"ShowOidColumn"="0"/
> /"FakeOidIndex"="0"/
> /"RowVersioning"="0"/
> /"ShowSystemTables"="0"/
> /"Protocol"="7.4-1"/
> /"ConnSettings"=""/
> /"DisallowPremature"="0"/
> /"UpdatableCursors"="0"/
> /"LFConversion"="1"/
> /"TrueIsMinus1"="1"/
> /"BI"="0"/
> /"AB"="0"/
> /"ByteaAsLongVarBinary"="0"/
> /"UseServerSidePrepare"="0"/
> /"LowerCaseIdentifier"="0"/
> /"GssAuthUseGSS"="0"/
> /"SSLmode"="allow"/
> /"XaOpt"="1"/
> /"KeepaliveTime"="-1"/
> /"KeepaliveInterval"="-1"/
>
>
> Maybe this can help you in debugging?
>
>
>
> Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> schrieb am Di., 12. Jan. 2016 um
> 00:21 Uhr:
>
>     On 01/11/2016 06:26 AM, Walter Willmertinger wrote:
>      > I installed the new version. Normal connection test was OK, but
>     not the
>      > special connection test in "Page 3".
>      >
>      > Using a postgresql database (8.4.22) with MS Access 2013 seemed
>     to work,
>      > but only read access. As soon as I try to change some data, I get the
>      > message "Another user has changed ...".
>      > I uninstalled the new version and installed the last release, now
>     it is
>      > working again.
>
>     When you ran the new version did you see if Row Versioning was checked?
>
>      >
>      > Regards, Walter
>      > --
>      >
>      > Viele Grüße
>      >
>      > Walter Willmertinger
>      >
>
>
>     --
>     Adrian Klaver
>     adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
> --
>
> Viele Grüße
>
> Walter Willmertinger
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 01/12/2016 08:22 AM, Walter Willmertinger wrote:
> I just installed the new psql-odbc-9-5..msi, started MS Access 2013 (64

As I understand the MSI's have been split out again, so which one did
you install x86, x64, or the all-in-one package?

> bit), opened a form where a Postgresql-table is connected by ODBC. So
> long as I do just read data, all is working. When I try to update data
> in this form (which is saved in the corresponding Postgresql-table), I
> get the write conflict.
>
> After uninstalling psql.odbc in Windows "Program and Features) and
> reinstalling the older 9-3 or 9.4 version, reading and updating is possible.

 From a specific package or the all-in-one installer?

>
>
> Adrian Klaver <adrian.klaver@aklaver.com
> <mailto:adrian.klaver@aklaver.com>> schrieb am Di., 12. Jan. 2016 um
> 16:58 Uhr:
>
>     On 01/12/2016 12:36 AM, Walter Willmertinger wrote:
>
>     Ccing list, so more eyes can see this.
>
>      > The "Write Conflict" is independent of the setting "row versioning".
>      > When I strted it was switched off. I switched to "On", but the
>     same result.
>
>     What did you do in between?
>
>     In other words did you disconnect/reconnect from the database, log
>     out/log in, rboot, etc?
>
>     I have had issues with ODBC not catching changes to its conf, especially
>     when there is a live connection.
>
>      >
>      > _Here is an excerpt from mylog:_
>      >
>      > /[7.065]conn=000001F55B153090, query='SELECT
>      >
>
"KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr"
>      > FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND "KdID" = 83'
>      > [8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE
>      > "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND
>     "KdID" =
>      > $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND
>      > "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS
>     NULL AND
>      > "ProgErledigt" = $8 AND "update_cs" = $9 AND
>      > "ZuletztBearbeitetPersonalNr" IS NULL
>      > [8.456]conn=000001F55B153090, query='BEGIN'
>      > [8.457]ParseWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET
>      > "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND
>     "DatumEreignis" =
>      > $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" =
>     $6 AND
>      > "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND
>      > "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
>      > [8.460]conn=000001F55B153090, query='UPDATE "public"."Notizen" SET
>      > "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND "KdID" = 83 AND
>      > "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND
>      > "AufnahmeDurchPersonalNr" = 80 AND "WeiterAnPersonalNr" = 80 AND
>      > "Status" = E'E' AND "Prioritaet" IS NULL AND "ProgErledigt" =
>     E'0' AND
>      > "update_cs" = E'2015-09-30 13:48:15'::timestamp AND
>      > "ZuletztBearbeitetPersonalNr" IS NULL'
>      > [8.464]conn=000001F55B153090, query='ROLLBACK'/
>
>     On the face of it the above looks alright. I have seen issues such as
>     you describe with Access and Postgres when using fractional second
>     timestamps, but the above uses integer seconds.
>
>      >
>      > _Here is my "ODBC.INI":_
>      > /[ODBC 32 bit Data Sources]/
>      > /PgSQL_CONSYS=PostgreSQL ANSI(x64) (32 bit)
>      > /
>      > /[PgSQL_CONSYS]
>      > /
>      > /Driver32=C:\Program Files\psqlODBC\0903\bin\psqlodbc30a.dll/
>      >
>      > *But it's Access 2013 64-bit!*
>
>     How did you install psqlodbc and from what source?
>
>     Also what OS and version are you running  on?
>
>     I do not fully understand the 32/64 bit thing in Windows, so I will
>     point you at this:
>
>     https://odbc.postgresql.org/faq.html#6.8
>
>      >
>      > _Here my registry settings for this ODBC-Entry:_
>      >
>      > /[HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\PgSQL_CONSYS]/
>      > /"Driver"="C:\\Program Files\\psqlODBC\\0903\\bin\\psqlodbc30a.dll"/
>      > /"CommLog"="1"/
>      > /"Debug"="0"/
>      > /"Fetch"="100"/
>      > /"Optimizer"="0"/
>      > /"Ksqo"="1"/
>      > /"UniqueIndex"="1"/
>      > /"UseDeclareFetch"="0"/
>      > /"UnknownSizes"="0"/
>      > /"TextAsLongVarchar"="1"/
>      > /"UnknownsAsLongVarchar"="0"/
>      > /"BoolsAsChar"="1"/
>      > /"Parse"="0"/
>      > /"CancelAsFreeStmt"="0"/
>      > /"MaxVarcharSize"="255"/
>      > /"MaxLongVarcharSize"="8190"/
>      > /"ExtraSysTablePrefixes"="dd_;"/
>      > /"Description"="Access 64 Bit"/
>      > /"Database"="consys"/
>      > /"Servername"="col"/
>      > /"Port"="5445"/
>      > /"Username"="XXXXX"/
>      > /"UID"="YYYYY"/
>      > /"Password"="ZZZZZZ"/
>      > /"ReadOnly"="0"/
>      > /"ShowOidColumn"="0"/
>      > /"FakeOidIndex"="0"/
>      > /"RowVersioning"="0"/
>      > /"ShowSystemTables"="0"/
>      > /"Protocol"="7.4-1"/
>      > /"ConnSettings"=""/
>      > /"DisallowPremature"="0"/
>      > /"UpdatableCursors"="0"/
>      > /"LFConversion"="1"/
>      > /"TrueIsMinus1"="1"/
>      > /"BI"="0"/
>      > /"AB"="0"/
>      > /"ByteaAsLongVarBinary"="0"/
>      > /"UseServerSidePrepare"="0"/
>      > /"LowerCaseIdentifier"="0"/
>      > /"GssAuthUseGSS"="0"/
>      > /"SSLmode"="allow"/
>      > /"XaOpt"="1"/
>      > /"KeepaliveTime"="-1"/
>      > /"KeepaliveInterval"="-1"/
>      >
>      >
>      > Maybe this can help you in debugging?
>      >
>      >
>      >
>      > Adrian Klaver <adrian.klaver@aklaver.com
>     <mailto:adrian.klaver@aklaver.com>
>      > <mailto:adrian.klaver@aklaver.com
>     <mailto:adrian.klaver@aklaver.com>>> schrieb am Di., 12. Jan. 2016 um
>      > 00:21 Uhr:
>      >
>      >     On 01/11/2016 06:26 AM, Walter Willmertinger wrote:
>      >      > I installed the new version. Normal connection test was
>     OK, but
>      >     not the
>      >      > special connection test in "Page 3".
>      >      >
>      >      > Using a postgresql database (8.4.22) with MS Access 2013
>     seemed
>      >     to work,
>      >      > but only read access. As soon as I try to change some
>     data, I get the
>      >      > message "Another user has changed ...".
>      >      > I uninstalled the new version and installed the last
>     release, now
>      >     it is
>      >      > working again.
>      >
>      >     When you ran the new version did you see if Row Versioning
>     was checked?
>      >
>      >      >
>      >      > Regards, Walter
>      >      > --
>      >      >
>      >      > Viele Grüße
>      >      >
>      >      > Walter Willmertinger
>      >      >
>      >
>      >
>      >     --
>      >     Adrian Klaver
>      > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>     <mailto:adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>>
>      >
>      > --
>      >
>      > Viele Grüße
>      >
>      > Walter Willmertinger
>      >
>
>
>     --
>     Adrian Klaver
>     adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
> --
>
> Viele Grüße
>
> Walter Willmertinger
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 01/12/2016 09:14 AM, Walter Willmertinger wrote:
> By the way, the OS is Windows 10 64 bit, MS Office is version 2013, also
> 64 bit.
> The FAQ is quite old, since Windows 8 the 64 bit odbc can be
> administered in the normal control area. You do not need the
> SYSWOW64-thing anymore.

Well as I understand it the SYSWOW64 bit was for administering the 32
bit ODBC not the 64 bit.

>
> Walter Willmertinger <willmis@gmail.com <mailto:willmis@gmail.com>>
> schrieb am Di., 12. Jan. 2016 um 18:06 Uhr:
>
>     Yesterday I tried the combined package, now after deinstalling I
>     tried the x64 and the x86 9.5.
>     Neither of them works for me (Write conflict after first try of
>     updating data).
>
>     After uninstalling 9.5 and installing 9.3.400 anything works again.
>
>     Adrian Klaver <adrian.klaver@aklaver.com
>     <mailto:adrian.klaver@aklaver.com>> schrieb am Di., 12. Jan. 2016 um
>     17:43 Uhr:
>
>         On 01/12/2016 08:22 AM, Walter Willmertinger wrote:
>          > I just installed the new psql-odbc-9-5..msi, started MS
>         Access 2013 (64
>
>         As I understand the MSI's have been split out again, so which
>         one did
>         you install x86, x64, or the all-in-one package?
>
>          > bit), opened a form where a Postgresql-table is connected by
>         ODBC. So
>          > long as I do just read data, all is working. When I try to
>         update data
>          > in this form (which is saved in the corresponding
>         Postgresql-table), I
>          > get the write conflict.
>          >
>          > After uninstalling psql.odbc in Windows "Program and
>         Features) and
>          > reinstalling the older 9-3 or 9.4 version, reading and
>         updating is possible.
>
>           From a specific package or the all-in-one installer?
>
>          >
>          >
>          > Adrian Klaver <adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>
>          > <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>> schrieb am Di., 12. Jan.
>         2016 um
>          > 16:58 Uhr:
>          >
>          >     On 01/12/2016 12:36 AM, Walter Willmertinger wrote:
>          >
>          >     Ccing list, so more eyes can see this.
>          >
>          >      > The "Write Conflict" is independent of the setting
>         "row versioning".
>          >      > When I strted it was switched off. I switched to "On",
>         but the
>          >     same result.
>          >
>          >     What did you do in between?
>          >
>          >     In other words did you disconnect/reconnect from the
>         database, log
>          >     out/log in, rboot, etc?
>          >
>          >     I have had issues with ODBC not catching changes to its
>         conf, especially
>          >     when there is a live connection.
>          >
>          >      >
>          >      > _Here is an excerpt from mylog:_
>          >      >
>          >      > /[7.065]conn=000001F55B153090, query='SELECT
>          >      >
>          >
>
"KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr"
>          >      > FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND
>         "KdID" = 83'
>          >      > [8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE
>          >      > "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" =
>         $2 AND
>          >     "KdID" =
>          >      > $3 AND "DatumEreignis" = $4 AND
>         "AufnahmeDurchPersonalNr" = $5 AND
>          >      > "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND
>         "Prioritaet" IS
>          >     NULL AND
>          >      > "ProgErledigt" = $8 AND "update_cs" = $9 AND
>          >      > "ZuletztBearbeitetPersonalNr" IS NULL
>          >      > [8.456]conn=000001F55B153090, query='BEGIN'
>          >      > [8.457]ParseWithLibpq: plan_name= query=UPDATE
>         "public"."Notizen" SET
>          >      > "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND
>          >     "DatumEreignis" =
>          >      > $4 AND "AufnahmeDurchPersonalNr" = $5 AND
>         "WeiterAnPersonalNr" =
>          >     $6 AND
>          >      > "Status" = $7 AND "Prioritaet" IS NULL AND
>         "ProgErledigt" = $8 AND
>          >      > "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
>          >      > [8.460]conn=000001F55B153090, query='UPDATE
>         "public"."Notizen" SET
>          >      > "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND
>         "KdID" = 83 AND
>          >      > "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND
>          >      > "AufnahmeDurchPersonalNr" = 80 AND
>         "WeiterAnPersonalNr" = 80 AND
>          >      > "Status" = E'E' AND "Prioritaet" IS NULL AND
>         "ProgErledigt" =
>          >     E'0' AND
>          >      > "update_cs" = E'2015-09-30 13:48:15'::timestamp AND
>          >      > "ZuletztBearbeitetPersonalNr" IS NULL'
>          >      > [8.464]conn=000001F55B153090, query='ROLLBACK'/
>          >
>          >     On the face of it the above looks alright. I have seen
>         issues such as
>          >     you describe with Access and Postgres when using
>         fractional second
>          >     timestamps, but the above uses integer seconds.
>          >
>          >      >
>          >      > _Here is my "ODBC.INI":_
>          >      > /[ODBC 32 bit Data Sources]/
>          >      > /PgSQL_CONSYS=PostgreSQL ANSI(x64) (32 bit)
>          >      > /
>          >      > /[PgSQL_CONSYS]
>          >      > /
>          >      > /Driver32=C:\Program
>         Files\psqlODBC\0903\bin\psqlodbc30a.dll/
>          >      >
>          >      > *But it's Access 2013 64-bit!*
>          >
>          >     How did you install psqlodbc and from what source?
>          >
>          >     Also what OS and version are you running  on?
>          >
>          >     I do not fully understand the 32/64 bit thing in Windows,
>         so I will
>          >     point you at this:
>          >
>          > https://odbc.postgresql.org/faq.html#6.8
>          >
>          >      >
>          >      > _Here my registry settings for this ODBC-Entry:_
>          >      >
>          >      > /[HKEY_CURRENT_USER\SOFTWARE\ODBC\ODBC.INI\PgSQL_CONSYS]/
>          >      > /"Driver"="C:\\Program
>         Files\\psqlODBC\\0903\\bin\\psqlodbc30a.dll"/
>          >      > /"CommLog"="1"/
>          >      > /"Debug"="0"/
>          >      > /"Fetch"="100"/
>          >      > /"Optimizer"="0"/
>          >      > /"Ksqo"="1"/
>          >      > /"UniqueIndex"="1"/
>          >      > /"UseDeclareFetch"="0"/
>          >      > /"UnknownSizes"="0"/
>          >      > /"TextAsLongVarchar"="1"/
>          >      > /"UnknownsAsLongVarchar"="0"/
>          >      > /"BoolsAsChar"="1"/
>          >      > /"Parse"="0"/
>          >      > /"CancelAsFreeStmt"="0"/
>          >      > /"MaxVarcharSize"="255"/
>          >      > /"MaxLongVarcharSize"="8190"/
>          >      > /"ExtraSysTablePrefixes"="dd_;"/
>          >      > /"Description"="Access 64 Bit"/
>          >      > /"Database"="consys"/
>          >      > /"Servername"="col"/
>          >      > /"Port"="5445"/
>          >      > /"Username"="XXXXX"/
>          >      > /"UID"="YYYYY"/
>          >      > /"Password"="ZZZZZZ"/
>          >      > /"ReadOnly"="0"/
>          >      > /"ShowOidColumn"="0"/
>          >      > /"FakeOidIndex"="0"/
>          >      > /"RowVersioning"="0"/
>          >      > /"ShowSystemTables"="0"/
>          >      > /"Protocol"="7.4-1"/
>          >      > /"ConnSettings"=""/
>          >      > /"DisallowPremature"="0"/
>          >      > /"UpdatableCursors"="0"/
>          >      > /"LFConversion"="1"/
>          >      > /"TrueIsMinus1"="1"/
>          >      > /"BI"="0"/
>          >      > /"AB"="0"/
>          >      > /"ByteaAsLongVarBinary"="0"/
>          >      > /"UseServerSidePrepare"="0"/
>          >      > /"LowerCaseIdentifier"="0"/
>          >      > /"GssAuthUseGSS"="0"/
>          >      > /"SSLmode"="allow"/
>          >      > /"XaOpt"="1"/
>          >      > /"KeepaliveTime"="-1"/
>          >      > /"KeepaliveInterval"="-1"/
>          >      >
>          >      >
>          >      > Maybe this can help you in debugging?
>          >      >
>          >      >
>          >      >
>          >      > Adrian Klaver <adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>
>          >     <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>
>          >      > <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>
>          >     <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>>> schrieb am Di., 12. Jan.
>         2016 um
>          >      > 00:21 Uhr:
>          >      >
>          >      >     On 01/11/2016 06:26 AM, Walter Willmertinger wrote:
>          >      >      > I installed the new version. Normal connection
>         test was
>          >     OK, but
>          >      >     not the
>          >      >      > special connection test in "Page 3".
>          >      >      >
>          >      >      > Using a postgresql database (8.4.22) with MS
>         Access 2013
>          >     seemed
>          >      >     to work,
>          >      >      > but only read access. As soon as I try to
>         change some
>          >     data, I get the
>          >      >      > message "Another user has changed ...".
>          >      >      > I uninstalled the new version and installed the
>         last
>          >     release, now
>          >      >     it is
>          >      >      > working again.
>          >      >
>          >      >     When you ran the new version did you see if Row
>         Versioning
>          >     was checked?
>          >      >
>          >      >      >
>          >      >      > Regards, Walter
>          >      >      > --
>          >      >      >
>          >      >      > Viele Grüße
>          >      >      >
>          >      >      > Walter Willmertinger
>          >      >      >
>          >      >
>          >      >
>          >      >     --
>          >      >     Adrian Klaver
>          >      > adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>
>         <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>
>          >     <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>
>         <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>>
>          >      >
>          >      > --
>          >      >
>          >      > Viele Grüße
>          >      >
>          >      > Walter Willmertinger
>          >      >
>          >
>          >
>          >     --
>          >     Adrian Klaver
>          > adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>         <mailto:adrian.klaver@aklaver.com
>         <mailto:adrian.klaver@aklaver.com>>
>          >
>          > --
>          >
>          > Viele Grüße
>          >
>          > Walter Willmertinger
>          >
>
>
>         --
>         Adrian Klaver
>         adrian.klaver@aklaver.com <mailto:adrian.klaver@aklaver.com>
>
>     --
>
>     Viele Grüße
>
>     Walter Willmertinger
>
> --
>
> Viele Grüße
>
> Walter Willmertinger
>


--
Adrian Klaver
adrian.klaver@aklaver.com

On 01/12/2016 09:05 AM, Walter Willmertinger wrote:
> Yesterday I tried the combined package, now after deinstalling I tried
> the x64 and the x86 9.5.
> Neither of them works for me (Write conflict after first try of updating
> data).
>
> After uninstalling 9.5 and installing 9.3.400 anything works again.
>

Hmm this is going to need someone with more knowledge of the internals
then I. My suspicion is that is has to do with the item below from the
9.5 Release Notes:

https://odbc.postgresql.org/docs/release.html

Use libpq for all communication with the server
Previously, libpq was only used for authentication. Using it for all
communication lets us remove a lot of duplicated code. libpq is now
required for building or using libpq.

My only reason for thinking this is from your MyLog excerpt:

query='BEGIN'[8.457]ParseWithLibpq:

and the fact that you are using a version of Postgres 8.4.22 that is no
longer supported. Best guess is that there is a libpq incompatibility.

Are there any errors in the MyLog when you used the psqlodbc 9.5 version?

--
Adrian Klaver
adrian.klaver@aklaver.com

Hi Walter and Heikki,

Probably I found the cause.

The "Write Conflict" is independent of the setting "row versioning". When I strted it was switched off. I switched to "On", but the same result.

Here is an excerpt from mylog:

[7.065]conn=000001F55B153090, query='SELECT "KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr" FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND "KdID" = 83'

Doesn't the target table contain boolean items?
Then the driver has to handle parse and describe message before executing the
update query.

[8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
[8.456]conn=000001F55B153090, query='BEGIN'
[8.457]ParseWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL

But a simple query is issued without using extended protocol because the
*Server side prepare* option is turned off.

[8.460]conn=000001F55B153090, query='UPDATE "public"."Notizen" SET "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND "KdID" = 83 AND "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND "AufnahmeDurchPersonalNr" = 80 AND "WeiterAnPersonalNr" = 80 AND "Status" = E'E' AND "Prioritaet" IS NULL AND "ProgErledigt" = E'0' AND "update_cs" = E'2015-09-30 13:48:15'::timestamp AND "ZuletztBearbeitetPersonalNr" IS NULL'

Though this update returns the response 'UPDATE 1', SQLRowCount() doesn't
work as expected due to SC_set_Result() in prepareParameters().

[8.464]conn=000001F55B153090, query='ROLLBACK'

One way to avoid the bug is to turn on the *Server side prepare*
option.
Though an appropriate bug fix is not clear to me, the attached
patch is an example.

regards,
Hiroshi Inoue

OK could you please try the drivers on testing for 9.5.0101 at
 http://www.ne.jp/asahi/inocchichichi/entrance/psqlodbc/
with *Server side prepare* off?

regards,
Hiroshi Inoue

I switched on "Server side prepare" and it is working better.

But in our VBA we programmed "Boolean" as "Char". So we switched this to "On" in settings.

Now we have no write conflict, but we get this message:

For testing purpose, I switched "Bool as Char" to "Off" and it seems to work with "Server side prepare".

So we will switch back to 9.3, as 9.4 and 9.5 are not working!

Regards

Walter Willmertinger

Inoue, Hiroshi <h-inoue@dream.email.ne.jp> schrieb am Mo., 18. Jan. 2016 um 13:38 Uhr:

Hi Walter and Heikki,

Probably I found the cause.

On 2016/01/12 17:36, Walter Willmertinger wrote:

The "Write Conflict" is independent of the setting "row versioning". When I strted it was switched off. I switched to "On", but the same result.

Here is an excerpt from mylog:

[7.065]conn=000001F55B153090, query='SELECT "KundenCode","DatumEreignis","AufnahmeDurchPersonalNr","WeiterAnPersonalNr","Status","Notiz","KdID","Prioritaet","ProgErledigt","update_cs","ZuletztBearbeitetPersonalNr" FROM "public"."Notizen" WHERE "KundenCode" = E'1' AND "KdID" = 83'

Doesn't the target table contain boolean items?
Then the driver has to handle parse and describe message before executing the
update query.

[8.455]ParseAndDescribeWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL
[8.456]conn=000001F55B153090, query='BEGIN'
[8.457]ParseWithLibpq: plan_name= query=UPDATE "public"."Notizen" SET "Notiz"=$1 WHERE "KundenCode" = $2 AND "KdID" = $3 AND "DatumEreignis" = $4 AND "AufnahmeDurchPersonalNr" = $5 AND "WeiterAnPersonalNr" = $6 AND "Status" = $7 AND "Prioritaet" IS NULL AND "ProgErledigt" = $8 AND "update_cs" = $9 AND "ZuletztBearbeitetPersonalNr" IS NULL

But a simple query is issued without using extended protocol because the
*Server side prepare* option is turned off.

[8.460]conn=000001F55B153090, query='UPDATE "public"."Notizen" SET "Notiz"=E'Test xxx' WHERE "KundenCode" = E'1' AND "KdID" = 83 AND "DatumEreignis" = E'2015-09-30 13:48:13'::timestamp AND "AufnahmeDurchPersonalNr" = 80 AND "WeiterAnPersonalNr" = 80 AND "Status" = E'E' AND "Prioritaet" IS NULL AND "ProgErledigt" = E'0' AND "update_cs" = E'2015-09-30 13:48:15'::timestamp AND "ZuletztBearbeitetPersonalNr" IS NULL'

Though this update returns the response 'UPDATE 1', SQLRowCount() doesn't
work as expected due to SC_set_Result() in prepareParameters().

[8.464]conn=000001F55B153090, query='ROLLBACK'

One way to avoid the bug is to turn on the *Server side prepare*
option.
Though an appropriate bug fix is not clear to me, the attached
patch is an example.

regards,
Hiroshi Inoue

このメッセージにウイルス は検出されませんでした。
AVG によってチェックされました - www.avg.com
バージョン： 2015.0.6176 / ウイルスデータベース：4522/11441 - リリース日：2016/01/19