Re: New 9.5.0100 does not work properly

Поиск
Список
Период
Сортировка
От Inoue, Hiroshi
Тема Re: New 9.5.0100 does not work properly
Дата
Msg-id 56A376DE.4050406@dream.email.ne.jp
обсуждение исходный текст
Ответ на Re: New 9.5.0100 does not work properly  (Walter Willmertinger <willmis@gmail.com>)
Список pgsql-odbc
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

On 2016/01/20 17:39, Walter Willmertinger wrote:
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:

Inline image 1

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


Вложения

В списке pgsql-odbc по дате отправления:

Предыдущее
От: "Inoue, Hiroshi"
Дата:
Сообщение: Re: Re: 9.0.5 issue - duplicate rows returned when using SQL_ATTR_ROW_ARRAY_SIZE attribute
Следующее
От: John Kew
Дата:
Сообщение: Re: Re: 9.0.5 issue - duplicate rows returned when using SQL_ATTR_ROW_ARRAY_SIZE attribute