Show max_identifier_length causes heavy query execution

--_aa6f7980-0433-4577-a78b-0261d67b5700_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable





Hello all=2C

I noticed that after executing a simple query
that takes few milliseconds=2C the odbc driver executes another query
which takes about 30 seconds to execute=2C because it scans a large table.
This is the part of the log file I think is showing the problem=2C see belo=
w for the entire log file:

[15.534]conn=3D02E72C78=2C query=3D'select count(*) from az001.doc101 where=
(code=2Criga)=3D(1=2C1)
'
[15.552] [ fetched 1 rows ]
[15.608]conn=3D02E72C78=2C query=3D'show max_identifier_length'
[15.619] [ fetched 1 rows ]
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes=2C desc=3D''=2C errnum=
=3D30=2C errmsg=3D'this request may be for MS SQL Server'

Then the driver executes the heavy query "SELECT * FROM az001.doc101"=2C wh=
ich retrieves about 1.5 million rows.

I came up with a workaround to avoid this problem=2C executing the query
SELECT (select count(*) from az001.doc101 where (code=2Criga)=3D(1=2C1))
instead
of the original one=2C but this problem seems to appear in many points of
the application=2C so i would like to find a better solution.

Here are some additional information=2C
the table structure is

CREATE TABLE az001.doc101
(
code integer NOT NULL=2C
riga integer NOT NULL=2C
subriga integer NOT NULL=2C
t_prog character varying(6) NOT NULL=2C
fd_a character varying=2C
fd_nd double precision=2C
fd_il integer=2C
fd_v double precision=2C
fd_d timestamp with time zone=2C
fd_sn boolean NOT NULL DEFAULT false=2C
CONSTRAINT doc101_pkey PRIMARY KEY (code=2C riga=2C subriga=2C t_prog)=2C
CONSTRAINT doc101_code_fkey1 FOREIGN KEY (code=2C riga=2C subriga)
REFERENCES az001.doc110 (code=2C riga=2C subriga) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (OIDS=3DFALSE)=3B

and this is the entire log file:

[0.060]conn=3D02E72C78=2C PGAPI_DriverConnect( in)=3D'DSN=3DPostgreSQL Log=
=3B'=2C fDriverCompletion=3D0
[0.082]DSN info: DSN=3D'PostgreSQL Log'=2Cserver=3D'localhost'=2Cport=3D'54=
32'=2Cdbase=3D'muna'=2Cuser=3D'client'=2Cpasswd=3D'xxxxx'
[0.091] onlyread=3D'0'=2Cprotocol=3D'7.4'=2Cshowoid=3D'0'=2Cfakeoi=
dindex=3D'0'=2Cshowsystable=3D'0'
[0.097] conn_settings=3D''=2C conn_encoding=3D'(null)'
[0.100] translation_dll=3D''=2Ctranslation_option=3D''
[0.116]Driver Version=3D'08.03.0300=2C200809260001' linking 1400 static Mul=
tithread library
[0.123]Global Options: fetch=3D100=2C socket=3D4096=2C unknown_sizes=3D2=2C=
max_varchar_size=3D255=2C max_longvarchar_size=3D8190
[0.131] disable_optimizer=3D0=2C ksqo=3D1=2C unique_index=3D=
1=2C use_declarefetch=3D0
[0.133] text_as_longvarchar=3D1=2C unknowns_as_longvarchar=
=3D0=2C bools_as_char=3D1 NAMEDATALEN=3D64
[0.136] extra_systable_prefixes=3D'dd_=3B'=2C conn_settings=
=3D'' conn_encoding=3D''
[0.544] [ PostgreSQL version string =3D '8.3.4' ]
[0.545] [ PostgreSQL version number =3D '8.3' ]
[0.565]conn=3D02E72C78=2C query=3D'select oid=2C typbasetype from pg_type w=
here typname =3D 'lo''
[0.586] [ fetched 0 rows ]
[0.601] [ Large Object oid =3D -999 ]
[0.602] [ Client encoding =3D 'UTF8' (code =3D 6) ]
[0.613]conn=3D02E72C78=2C
PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL
Log=3BDATABASE=3Dmuna=3BSERVER=3Dlocalhost=3BPORT=3D5432=3BU ID=3Dclient=3BP=
WD=3Dxxxxxx=3BSSLmode=3Ddisable=3BReadOnly=3D0=3BProtocol=3D 7.4-1=3BFakeOid=
Index=3D0=3BShowOidColumn=3D0=3BRowVersioning=3D0=3BShowSyst emTables=3D0=3B=
ConnSettings=3D=3BFetch=3D100=3BSocket=3D4096=3BUnknownSizes =3D2=3BMaxVarch=
arSize=3D255=3BMaxLongVarcharSize=3D8190=3BDebug=3D1=3BCommL og=3D1=3BOptimi=
zer=3D0=3BKsqo=3D1=3BUseDeclareFetch=3D0=3BTextAsLongVarchar =3D1=3BUnknowns=
AsLongVarchar=3D0=3BBoolsAsChar=3D1=3BParse=3D0=3BCancelAsFr eeStmt=3D0=3BEx=
traSysTablePrefixes=3Ddd_=3B=3BLFConversion=3D1=3BUpdatableC ursors=3D1=3BDi=
sallowPremature=3D0=3BTrueIsMinus1=3D0=3BBI=3D0=3BByteaAsLon gVarBinary=3D1=
=3BUseServerSidePrepare=3D0=3BLowerCaseIdentifier=3D0=3BXaOp t=3D1'
[15.534]conn=3D02E72C78=2C query=3D'select count(*) from az001.doc101 where=
(code=2Criga)=3D(1=2C1)
'
[15.552] [ fetched 1 rows ]
[15.608]conn=3D02E72C78=2C query=3D'show max_identifier_length'
[15.619] [ fetched 1 rows ]
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes=2C desc=3D''=2C errnum=
=3D30=2C errmsg=3D'this request may be for MS SQL Server'
[15.663] --------------------------------------------------=
----------
[15.664] hdbc=3D02E72C78=2C stmt=3D02E77808=2C result=3D02E=
70EA0
[15.665] prepare=3D0=2C internal=3D0
[15.666] bindings=3D02E791E8=2C bindings_allocated=3D1
[15.667] parameters=3D00000000=2C parameters_allocated=3D0
[15.668] statement_type=3D0=2C statement=3D'select count(*)=
from az001.doc101 where (code=2Criga)=3D(1=2C1)
'
[15.670] stmt_with_params=3D'select count(*) from az001.doc=
101 where (code=2Criga)=3D(1=2C1)
'
[15.671] data_at_exec=3D-1=2C current_exec_param=3D-1=2C pu=
t_data=3D0
[15.672] currTuple=3D-1=2C current_col=3D-1=2C lobj_fd=3D-1
[15.673] maxRows=3D0=2C rowset_size=3D1=2C keyset_size=3D0=
=2C cursor_type=3D0=2C scroll_concurrency=3D1
[15.674] cursor_name=3D'SQL_CUR02E77808'
[15.675] ----------------QResult Info ---------------------=
----------
[15.677] fields=3D02E77BA8=2C backend_tuples=3D02E78E70=2C =
tupleField=3D48729712=2C conn=3D02E72C78
[15.678] fetch_count=3D0=2C num_total_rows=3D1=2C num_field=
s=3D1=2C cursor=3D'(NULL)'
[15.679] message=3D'(NULL)'=2C command=3D'SELECT'=2C notice=
=3D'(NULL)'
[15.680] status=3D100=2C inTuples=3D0
[15.681]CONN ERROR: func=3DPGAPI_ColAttributes=2C desc=3D''=2C errnum=3D0=
=2C errmsg=3D'(NULL)'
[15.683] -------------------------------------------------------=
-----
[15.685] henv=3D02E72C38=2C conn=3D02E72C78=2C status=3D1=2C num=
_stmts=3D16
[15.687] sock=3D02E70A08=2C stmts=3D02E70AE0=2C lobj_type=3D-999
[15.688] ---------------- Socket Info --------------------------=
-----
[15.690] socket=3D552=2C reverse=3D0=2C errornumber=3D0=2C error=
msg=3D'(NULL)'
[15.692] buffer_in=3D48715736=2C buffer_out=3D48719856
[15.692] buffer_filled_in=3D76=2C buffer_filled_out=3D0=2C buffe=
r_read_in=3D76
[15.735]CONN ERROR: func=3DSQLNativeSqlW=2C desc=3D''=2C errnum=3D-2=2C err=
msg=3D'Sql string too large'
[15.737] -------------------------------------------------------=
-----
[15.738] henv=3D02E72C38=2C conn=3D02E72C78=2C status=3D1=2C num=
_stmts=3D16
[15.739] sock=3D02E70A08=2C stmts=3D02E70AE0=2C lobj_type=3D-999
[15.740] ---------------- Socket Info --------------------------=
-----
[15.741] socket=3D552=2C reverse=3D0=2C errornumber=3D0=2C error=
msg=3D'(NULL)'
[15.743] buffer_in=3D48715736=2C buffer_out=3D48719856
[15.743] buffer_filled_in=3D76=2C buffer_filled_out=3D0=2C buffe=
r_read_in=3D76
[15.772]conn=3D02E72C78=2C query=3D'SELECT * FROM az001.doc101'


Thanks in advance=2C I apologize for my poor english.

Regards=2C

Moreno Dissegna
Developer
S.A. Software S.r.l.
____________________________________________________________ _____
Pi=F9 di 30 stazioni. Ascolta la Radio su Messenger!
http://messenger.it/radioMessenger.aspx=

--_aa6f7980-0433-4577-a78b-0261d67b5700_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
..hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>



Hello all=2C<br><br>I noticed that after executing a simple query
that takes few milliseconds=2C the odbc driver executes another query
which takes about 30 seconds to execute=2C because it scans a large table.<=
br>This is the part of the log file I think is showing the problem=2C see b=
elow for the entire log file:<br><br>[15.534]conn=3D02E72C78=2C query=3D'se=
lect count(*) from az001.doc101 where (code=2Criga)=3D(1=2C1)<br>'<br>[15.5=
52] =3B =3B =3B [ fetched 1 rows ]<br>[15.608]conn=3D02E72C78=
=2C query=3D'show max_identifier_length'<br>[15.619] =3B =3B =
=3B [ fetched 1 rows ]<br>[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttribut=
es=2C desc=3D''=2C errnum=3D30=2C errmsg=3D'this request may be for MS SQL =
Server'<br><br>Then the driver executes the heavy query "SELECT * FROM az00=
1.doc101"=2C which retrieves about 1.5 million rows.<br><br>I came up with =
a workaround to avoid this problem=2C executing the query <br>SELECT (selec=
t count(*) from az001.doc101 where (code=2Criga)=3D(1=2C1))<br>instead
of the original one=2C but this problem seems to appear in many points of
the application=2C so i would like to find a better solution.<br><br>Here a=
re some additional information=2C<br>the table structure is<br><br>CREATE T=
ABLE az001.doc101<br>(<br> =3B code integer NOT NULL=2C<br> =3B rig=
a integer NOT NULL=2C<br> =3B subriga integer NOT NULL=2C<br> =3B t=
_prog character varying(6) NOT NULL=2C<br> =3B fd_a character varying=
=2C<br> =3B fd_nd double precision=2C<br> =3B fd_il integer=2C<br>&=
nbsp=3B fd_v double precision=2C<br> =3B fd_d timestamp with time zone=
=2C<br> =3B fd_sn boolean NOT NULL DEFAULT false=2C<br> =3B CONSTRA=
INT doc101_pkey PRIMARY KEY (code=2C riga=2C subriga=2C t_prog)=2C<br> =
=3B CONSTRAINT doc101_code_fkey1 FOREIGN KEY (code=2C riga=2C subriga)<br>&=
nbsp=3B =3B =3B =3B =3B REFERENCES az001.doc110 (code=2C ri=
ga=2C subriga) MATCH SIMPLE<br> =3B =3B =3B =3B =3B ON =
UPDATE CASCADE ON DELETE CASCADE<br>)<br>WITH (OIDS=3DFALSE)=3B<br><br>and =
this is the entire log file:<br><br>[0.060]conn=3D02E72C78=2C PGAPI_DriverC=
onnect( in)=3D'DSN=3DPostgreSQL Log=3B'=2C fDriverCompletion=3D0<br>[0.082]=
DSN info: DSN=3D'PostgreSQL Log'=2Cserver=3D'localhost'=2Cport=3D'5432'=2Cd=
base=3D'muna'=2Cuser=3D'client'=2Cpasswd=3D'xxxxx'<br>[0.091] =3B =
=3B =3B =3B =3B =3B =3B =3B =3B onlyread=3D'0'=
=2Cprotocol=3D'7.4'=2Cshowoid=3D'0'=2Cfakeoidindex=3D'0'=2Cs howsystable=3D'=
0'<br> [0.097] =3B =3B =3B =3B =3B =3B  =3B =
=3B =3B conn_settings=3D''=2C conn_encoding=3D'(null)'<br>[0.100] =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B transla=
tion_dll=3D''=2Ctranslation_option=3D''<br>[0.116]Driver Version=3D'08.03.0=
300=2C200809260001' linking 1400 static Multithread library<br>[0.123]Globa=
l Options: fetch=3D100=2C socket=3D4096=2C unknown_sizes=3D2=2C max_varchar=
_size=3D255=2C max_longvarchar_size=3D8190<br>[0.131] =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B =3B disable_optimizer=3D0=2C ksqo=3D1=2C unique_index=
=3D1=2C use_declarefetch=3D0<br>[0.133] =3B =3B =3B =3B&nbs=
p=3B =3B =3B =3B =3B =3B =3B =3B  =3B =
=3B =3B text_as_longvarchar=3D1=2C unknowns_as_longvarchar=3D0=2C bools=
_as_char=3D1 NAMEDATALEN=3D64<br>[0.136] =3B =3B =3B =3B&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3 B =3B =
=3B =3B extra_systable_prefixes=3D'dd_=3B'=2C conn_settings=3D'' conn_e=
ncoding=3D''<br>[0.544] =3B =3B =3B [ PostgreSQL version string=
=3D '8.3.4' ]<br>[0.545] =3B =3B =3B [ PostgreSQL version numb=
er =3D '8.3' ]<br>[0.565]conn=3D02E72C78=2C query=3D'select oid=2C typbaset=
ype from pg_type where typname =3D 'lo''<br>[0.586] =3B =3B =3B=
[ fetched 0 rows ]<br>[0.601] =3B =3B =3B [ Large Object oid =
=3D -999 ]<br>[0.602] =3B =3B =3B [ Client encoding =3D 'UTF8' =
(code =3D 6) ]<br>[0.613]conn=3D02E72C78=2C
PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL
Log=3BDATABASE=3Dmuna=3BSERVER=3Dlocalhost=3BPORT=3D5432=3BU ID=3Dclient=3BP=
WD=3Dxxxxxx=3BSSLmode=3Ddisable=3BReadOnly=3D0=3BProtocol=3D 7.4-1=3BFakeOid=
Index=3D0=3BShowOidColumn=3D0=3BRowVersioning=3D0=3BShowSyst emTables=3D0=3B=
ConnSettings=3D=3BFetch=3D100=3BSocket=3D4096=3BUnknownSizes =3D2=3BMaxVarch=
arSize=3D255=3BMaxLongVarcharSize=3D8190=3BDebug=3D1=3BCommL og=3D1=3BOptimi=
zer=3D0=3BKsqo=3D1=3BUseDeclareFetch=3D0=3BTextAsLongVarchar =3D1=3BUnknowns=
AsLongVarchar=3D0=3BBoolsAsChar=3D1=3BParse=3D0=3BCancelAsFr eeStmt=3D0=3BEx=
traSysTablePrefixes=3Ddd_=3B=3BLFConversion=3D1=3BUpdatableC ursors=3D1=3BDi=
sallowPremature=3D0=3BTrueIsMinus1=3D0=3BBI=3D0=3BByteaAsLon gVarBinary=3D1=
=3BUseServerSidePrepare=3D0=3BLowerCaseIdentifier=3D0=3BXaOp t=3D1'<br>[15.5=
34]conn=3D02E72C78=2C query=3D'select count(*) from az001.doc101 where (cod=
e=2Criga)=3D(1=2C1)<br>'<br>[15.552] =3B =3B =3B [ fetched 1 ro=
ws ]<br>[15.608]conn=3D02E72C78=2C query=3D'show max_identifier_length'<br>=
[15.619] =3B =3B =3B [ fetched 1 rows ]<br>[15.660]STATEMENT ER=
ROR: func=3DPGAPI_ColAttributes=2C desc=3D''=2C errnum=3D30=2C errmsg=3D'th=
is request may be for MS SQL Server'<br>[15.663] =3B =3B =3B&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3 B =3B =
=3B =3B =3B =3B -----------------------------------------------=
-------------<br>[15.664] =3B =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B =3B =3B = 3B =3B =
=3B hdbc=3D02E72C78=2C stmt=3D02E77808=2C result=3D02E70EA0<br>[15.665]&nbs=
p=3B =3B =3B =3B =3B =3B =3B =3B  =3B =
=3B =3B =3B =3B =3B =3B =3B prepare=3D0=2C internal=
=3D0<br> [15.666] =3B =3B =3B =3B =3B =3B&nbs p=3B&nb=
sp=3B =3B =3B =3B =3B =3B =3B =3 B =3B bindi=
ngs=3D02E791E8=2C bindings_allocated=3D1<br>[15.667] =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B =3B =3B parameters=3D00000000=2C parameters_alloca=
ted=3D0<br> [15.668] =3B =3B =3B =3B =3B =3B&nbs p=3B=
 =3B =3B =3B =3B =3B =3B =3B&nbs p=3B =3B st=
atement_type=3D0=2C statement=3D'select count(*) from az001.doc101 where (c=
ode=2Criga)=3D(1=2C1)<br>'<br>[15.670] =3B =3B =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B stmt_with_params=3D'select count(*) from az001.doc101 wher=
e (code=2Criga)=3D(1=2C1)<br>'<br>[15.671] =3B =3B =3B =3B&=
nbsp=3B =3B =3B =3B =3B =3B =3B  =3B =3B&nbs=
p=3B =3B =3B data_at_exec=3D-1=2C current_exec_param=3D-1=2C put_da=
ta=3D0<br> [15.672] =3B =3B =3B =3B =3B =3B&nbs p=3B&=
nbsp=3B =3B =3B =3B =3B =3B =3B  =3B =3B cur=
rTuple=3D-1=2C current_col=3D-1=2C lobj_fd=3D-1<br>[15.673] =3B =3B=
 =3B =3B =3B =3B =3B =3B =3B&nbs p=3B =3B&nb=
sp=3B =3B =3B =3B =3B maxRows=3D0=2C rowset_size=3D1=2C key=
set_size=3D0=2C cursor_type=3D0=2C scroll_concurrency=3D1<br>[15.674] =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B =3B =3B =3B =3B cursor_name=3D'SQL_CUR02E7=
7808'<br> [15.675] =3B =3B =3B =3B =3B =3B&nbs p=3B&n=
bsp=3B =3B =3B =3B =3B =3B =3B = 3B =3B ----=
------------QResult Info -------------------------------<br>[15.677] =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B =3B =3B =3B =3B fields=3D02E77BA8=2C backe=
nd_tuples=3D02E78E70=2C tupleField=3D48729712=2C conn=3D02E72C78<br>[15.678=
] =3B =3B =3B =3B =3B =3B =3B&nb sp=3B =3B&n=
bsp=3B =3B =3B =3B =3B =3B =3B fetch_count=3D0=2C n=
um_total_rows=3D1=2C num_fields=3D1=2C cursor=3D'(NULL)'<br>[15.679] =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B =3B =3B =3B =3B =3B message=3D'(NULL)'=2C comm=
and=3D'SELECT'=2C notice=3D'(NULL)'<br>[15.680] =3B =3B =3B&nbs=
p=3B =3B =3B =3B =3B =3B =3B =3B  =3B =
=3B =3B =3B =3B status=3D100=2C inTuples=3D0<br>[15.681]CONN ER=
ROR: func=3DPGAPI_ColAttributes=2C desc=3D''=2C errnum=3D0=2C errmsg=3D'(NU=
LL)'<br> [15.683] =3B =3B =3B =3B =3B =3B&nbs p=3B&nb=
sp=3B =3B =3B =3B ---------------------------------------------=
---------------<br>[15.685] =3B =3B =3B =3B =3B =3B=
 =3B =3B =3B =3B =3B henv=3D02E72C38=2C conn=3D02E72C78=
=2C status=3D1=2C num_stmts=3D16<br>[15.687] =3B =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B sock=3D02E70A08=
=2C stmts=3D02E70AE0=2C lobj_type=3D-999<br>[15.688] =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B -------=
--------- Socket Info -------------------------------<br>[15.690] =3B&n=
bsp=3B =3B =3B =3B =3B =3B =3B = 3B =3B =
=3B socket=3D552=2C reverse=3D0=2C errornumber=3D0=2C errormsg=3D'(NULL)'<b=
r>[15.692] =3B =3B =3B =3B =3B =3B&n bsp=3B =3B&=
nbsp=3B =3B =3B buffer_in=3D48715736=2C buffer_out=3D48719856<br>[1=
5.692] =3B =3B =3B =3B =3B =3B = 3B =3B =
=3B =3B =3B buffer_filled_in=3D76=2C buffer_filled_out=3D0=2C buffe=
r_read_in=3D76<br>[15.735]CONN ERROR: func=3DSQLNativeSqlW=2C desc=3D''=2C =
errnum=3D-2=2C errmsg=3D'Sql string too large'<br>[15.737] =3B =3B&=
nbsp=3B =3B =3B =3B =3B =3B =3B  =3B =3B ---=
---------------------------------------------------------<br>[15.738] =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B =3B=
 =3B henv=3D02E72C38=2C conn=3D02E72C78=2C status=3D1=2C num_stmts=3D16=
<br> [15.739] =3B =3B =3B =3B =3B =3B&nbs p=3B =
=3B =3B =3B =3B sock=3D02E70A08=2C stmts=3D02E70AE0=2C lobj_typ=
e=3D-999<br> [15.740] =3B =3B =3B =3B =3B =3B&nbs p=
=3B =3B =3B =3B =3B ---------------- Socket Info ----------=
---------------------<br>[15.741] =3B =3B =3B =3B =3B&n=
bsp=3B =3B =3B =3B =3B =3B socket=3D552=2C reverse=3D0=
=2C errornumber=3D0=2C errormsg=3D'(NULL)'<br>[15.743] =3B =3B =
=3B =3B =3B =3B =3B =3B =3B =3B& nbsp=3B buffer_=
in=3D48715736=2C buffer_out=3D48719856<br>[15.743] =3B =3B =3B&=
nbsp=3B =3B =3B =3B =3B =3B =3B  =3B buffer_fill=
ed_in=3D76=2C buffer_filled_out=3D0=2C buffer_read_in=3D76<br>[15.772]conn=
=3D02E72C78=2C query=3D'SELECT * FROM az001.doc101'<br><br><br>Thanks in ad=
vance=2C I apologize for my poor english.<br><br>Regards=2C<br><br>Moreno D=
issegna<br>Developer<br>S.A. Software S.r.l.
<hr />Scrivi=2C parla e g=
ioca con i tuoi amici! <a href=3D'http://messenger.it/gioca.aspx' target=3D=
'_new'>Scarica Messenger 2009!</a></body>
</html>=

--_aa6f7980-0433-4577-a78b-0261d67b5700_--
moreno.d [ Di, 26 Mai 2009 18:48 ] [ ID #2002820 ]

Re: Show max_identifier_length causes heavy query execution

--_000_C6419E611F0ksellgreenplumcom_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Hi,

I'm the new connectivity engineer.

I'm attempting to recreate the problem, but haven't seen the same results a=
s you.
Can you send me the sequence of ODBC statements that cause the problem?

Thanks,

.....Ken Sell


On 5/26/09 9:48 AM, "Moreno D." <moreno.d [at] hotmail.it> wrote:

Hello all,

I noticed that after executing a simple query that takes few milliseconds, =
the odbc driver executes another query which takes about 30 seconds to exec=
ute, because it scans a large table.
This is the part of the log file I think is showing the problem, see below =
for the entire log file:

[15.534]conn=3D02E72C78, query=3D'select count(*) from az001.doc101 where (=
code,riga)=3D(1,1)
'
[15.552] [ fetched 1 rows ]
[15.608]conn=3D02E72C78, query=3D'show max_identifier_length'
[15.619] [ fetched 1 rows ]
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D30=
, errmsg=3D'this request may be for MS SQL Server'

Then the driver executes the heavy query "SELECT * FROM az001.doc101", whic=
h retrieves about 1.5 million rows.

I came up with a workaround to avoid this problem, executing the query
SELECT (select count(*) from az001.doc101 where (code,riga)=3D(1,1))
instead of the original one, but this problem seems to appear in many point=
s of the application, so i would like to find a better solution.

Here are some additional information,
the table structure is

CREATE TABLE az001.doc101
(
code integer NOT NULL,
riga integer NOT NULL,
subriga integer NOT NULL,
t_prog character varying(6) NOT NULL,
fd_a character varying,
fd_nd double precision,
fd_il integer,
fd_v double precision,
fd_d timestamp with time zone,
fd_sn boolean NOT NULL DEFAULT false,
CONSTRAINT doc101_pkey PRIMARY KEY (code, riga, subriga, t_prog),
CONSTRAINT doc101_code_fkey1 FOREIGN KEY (code, riga, subriga)
REFERENCES az001.doc110 (code, riga, subriga) MATCH SIMPLE
ON UPDATE CASCADE ON DELETE CASCADE
)
WITH (OIDS=3DFALSE);

and this is the entire log file:

[0.060]conn=3D02E72C78, PGAPI_DriverConnect( in)=3D'DSN=3DPostgreSQL Log;',=
fDriverCompletion=3D0
[0.082]DSN info: DSN=3D'PostgreSQL Log',server=3D'localhost',port=3D'5432',=
dbase=3D'muna',user=3D'client',passwd=3D'xxxxx'
[0.091] onlyread=3D'0',protocol=3D'7.4',showoid=3D'0',fakeoidindex=
=3D'0',showsystable=3D'0'
[0.097] conn_settings=3D'', conn_encoding=3D'(null)'
[0.100] translation_dll=3D'',translation_option=3D''
[0.116]Driver Version=3D'08.03.0300,200809260001' linking 1400 static Multi=
thread library
[0.123]Global Options: fetch=3D100, socket=3D4096, unknown_sizes=3D2, max_v=
archar_size=3D255, max_longvarchar_size=3D8190
[0.131] disable_optimizer=3D0, ksqo=3D1, unique_index=3D1, u=
se_declarefetch=3D0
[0.133] text_as_longvarchar=3D1, unknowns_as_longvarchar=3D0=
, bools_as_char=3D1 NAMEDATALEN=3D64
[0.136] extra_systable_prefixes=3D'dd_;', conn_settings=3D''=
conn_encoding=3D''
[0.544] [ PostgreSQL version string =3D '8.3.4' ]
[0.545] [ PostgreSQL version number =3D '8.3' ]
[0.565]conn=3D02E72C78, query=3D'select oid, typbasetype from pg_type where=
typname =3D 'lo''
[0.586] [ fetched 0 rows ]
[0.601] [ Large Object oid =3D -999 ]
[0.602] [ Client encoding =3D 'UTF8' (code =3D 6) ]
[0.613]conn=3D02E72C78, PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL Log;DA=
TABASE=3Dmuna;SERVER=3Dlocalhost;PORT=3D5432;UID=3Dclient;PW D=3Dxxxxxx;SSLm=
ode=3Ddisable;ReadOnly=3D0;Protocol=3D7.4-1;FakeOidIndex=3D0 ;ShowOidColumn=
=3D0;RowVersioning=3D0;ShowSystemTables=3D0;ConnSettings=3D; Fetch=3D100;Soc=
ket=3D4096;UnknownSizes=3D2;MaxVarcharSize=3D255;MaxLongVarc harSize=3D8190;=
Debug=3D1;CommLog=3D1;Optimizer=3D0;Ksqo=3D1;UseDeclareFetch =3D0;TextAsLong=
Varchar=3D1;UnknownsAsLongVarchar=3D0;BoolsAsChar=3D1;Parse= 3D0;CancelAsFre=
eStmt=3D0;ExtraSysTablePrefixes=3Ddd_;;LFConversion=3D1;Upda tableCursors=3D=
1;DisallowPremature=3D0;TrueIsMinus1=3D0;BI=3D0;ByteaAsLongV arBinary=3D1;Us=
eServerSidePrepare=3D0;LowerCaseIdentifier=3D0;XaOpt=3D1'
[15.534]conn=3D02E72C78, query=3D'select count(*) from az001.doc101 where (=
code,riga)=3D(1,1)
'
[15.552] [ fetched 1 rows ]
[15.608]conn=3D02E72C78, query=3D'show max_identifier_length'
[15.619] [ fetched 1 rows ]
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D30=
, errmsg=3D'this request may be for MS SQL Server'
[15.663] --------------------------------------------------=
----------
[15.664] hdbc=3D02E72C78, stmt=3D02E77808, result=3D02E70EA=
0
[15.665] prepare=3D0, internal=3D0
[15.666] bindings=3D02E791E8, bindings_allocated=3D1
[15.667] parameters=3D00000000, parameters_allocated=3D0
[15.668] statement_type=3D0, statement=3D'select count(*) f=
rom az001.doc101 where (code,riga)=3D(1,1)
'
[15.670] stmt_with_params=3D'select count(*) from az001.doc=
101 where (code,riga)=3D(1,1)
'
[15.671] data_at_exec=3D-1, current_exec_param=3D-1, put_da=
ta=3D0
[15.672] currTuple=3D-1, current_col=3D-1, lobj_fd=3D-1
[15.673] maxRows=3D0, rowset_size=3D1, keyset_size=3D0, cur=
sor_type=3D0, scroll_concurrency=3D1
[15.674] cursor_name=3D'SQL_CUR02E77808'
[15.675] ----------------QResult Info ---------------------=
----------
[15.677] fields=3D02E77BA8, backend_tuples=3D02E78E70, tupl=
eField=3D48729712, conn=3D02E72C78
[15.678] fetch_count=3D0, num_total_rows=3D1, num_fields=3D=
1, cursor=3D'(NULL)'
[15.679] message=3D'(NULL)', command=3D'SELECT', notice=3D'=
(NULL)'
[15.680] status=3D100, inTuples=3D0
[15.681]CONN ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D0, errm=
sg=3D'(NULL)'
[15.683] -------------------------------------------------------=
-----
[15.685] henv=3D02E72C38, conn=3D02E72C78, status=3D1, num_stmts=
=3D16
[15.687] sock=3D02E70A08, stmts=3D02E70AE0, lobj_type=3D-999
[15.688] ---------------- Socket Info --------------------------=
-----
[15.690] socket=3D552, reverse=3D0, errornumber=3D0, errormsg=3D=
'(NULL)'
[15.692] buffer_in=3D48715736, buffer_out=3D48719856
[15.692] buffer_filled_in=3D76, buffer_filled_out=3D0, buffer_re=
ad_in=3D76
[15.735]CONN ERROR: func=3DSQLNativeSqlW, desc=3D'', errnum=3D-2, errmsg=3D=
'Sql string too large'
[15.737] -------------------------------------------------------=
-----
[15.738] henv=3D02E72C38, conn=3D02E72C78, status=3D1, num_stmts=
=3D16
[15.739] sock=3D02E70A08, stmts=3D02E70AE0, lobj_type=3D-999
[15.740] ---------------- Socket Info --------------------------=
-----
[15.741] socket=3D552, reverse=3D0, errornumber=3D0, errormsg=3D=
'(NULL)'
[15.743] buffer_in=3D48715736, buffer_out=3D48719856
[15.743] buffer_filled_in=3D76, buffer_filled_out=3D0, buffer_re=
ad_in=3D76
[15.772]conn=3D02E72C78, query=3D'SELECT * FROM az001.doc101'


Thanks in advance, I apologize for my poor english.

Regards,

Moreno Dissegna
Developer
S.A. Software S.r.l.
________________________________
Scrivi, parla e gioca con i tuoi amici! Scarica Messenger 2009! <http://mes=
senger.it/gioca.aspx>

--_000_C6419E611F0ksellgreenplumcom_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<HTML>
<HEAD>
<TITLE>Re: [ODBC] Show max_identifier_length causes heavy query execution</=
TITLE>
</HEAD>
<BODY>
<FONT FACE=3D"Calibri, Verdana, Helvetica, Arial"><SPAN STYLE=3D'font-size:=
11pt'>Hi,<BR>
<BR>
I’m the new connectivity engineer.<BR>
<BR>
I’m attempting to recreate the problem, but haven’t seen the sa=
me results as you.<BR>
Can you send me the sequence of ODBC statements that cause the problem?<BR>
<BR>
Thanks,<BR>
<BR>
.....Ken Sell<BR>
<BR>
<BR>
On 5/26/09 9:48 AM, "Moreno D." <<a href=3D"moreno.d [at] hotmail.i=
t">moreno.d [at] hotmail.it</a>> wrote:<BR>
<BR>
</SPAN></FONT><BLOCKQUOTE><FONT SIZE=3D"2"><FONT FACE=3D"Verdana, Helvetica=
, Arial"><SPAN STYLE=3D'font-size:10pt'>Hello all,<BR>
<BR>
I noticed that after executing a simple query that takes few milliseconds, =
the odbc driver executes another query which takes about 30 seconds to exec=
ute, because it scans a large table.<BR>
This is the part of the log file I think is showing the problem, see below =
for the entire log file:<BR>
<BR>
[15.534]conn=3D02E72C78, query=3D'select count(*) from az001.doc101 where (=
code,riga)=3D(1,1)<BR>
'<BR>
[15.552]    [ fetched 1 rows ]<BR>
[15.608]conn=3D02E72C78, query=3D'show max_identifier_length'<BR>
[15.619]    [ fetched 1 rows ]<BR>
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D30=
, errmsg=3D'this request may be for MS SQL Server'<BR>
<BR>
Then the driver executes the heavy query "SELECT * FROM az001.doc101&q=
uot;, which retrieves about 1.5 million rows.<BR>
<BR>
I came up with a workaround to avoid this problem, executing the query <BR>
SELECT (select count(*) from az001.doc101 where (code,riga)=3D(1,1))<BR>
instead of the original one, but this problem seems to appear in many point=
s of the application, so i would like to find a better solution.<BR>
<BR>
Here are some additional information,<BR>
the table structure is<BR>
<BR>
CREATE TABLE az001.doc101<BR>
(<BR>
  code integer NOT NULL,<BR>
  riga integer NOT NULL,<BR>
  subriga integer NOT NULL,<BR>
  t_prog character varying(6) NOT NULL,<BR>
  fd_a character varying,<BR>
  fd_nd double precision,<BR>
  fd_il integer,<BR>
  fd_v double precision,<BR>
  fd_d timestamp with time zone,<BR>
  fd_sn boolean NOT NULL DEFAULT false,<BR>
  CONSTRAINT doc101_pkey PRIMARY KEY (code, riga, subriga, t_prog=
),<BR>
  CONSTRAINT doc101_code_fkey1 FOREIGN KEY (code, riga, subriga)<=
BR>
      REFERENCES az001.doc110 (code, riga, su=
briga) MATCH SIMPLE<BR>
      ON UPDATE CASCADE ON DELETE CASCADE<BR>
)<BR>
WITH (OIDS=3DFALSE);<BR>
<BR>
and this is the entire log file:<BR>
<BR>
[0.060]conn=3D02E72C78, PGAPI_DriverConnect( in)=3D'DSN=3DPostgreSQL Log;',=
fDriverCompletion=3D0<BR>
[0.082]DSN info: DSN=3D'PostgreSQL Log',server=3D'localhost',port=3D'5432',=
dbase=3D'muna',user=3D'client',passwd=3D'xxxxx'<BR>
[0.091]          onlyread=3D'0=
',protocol=3D'7.4',showoid=3D'0',fakeoidindex=3D'0',showsyst able=3D'0'<BR>
[0.097]          conn_settings=
=3D'', conn_encoding=3D'(null)'<BR>
[0.100]          translation_d=
ll=3D'',translation_option=3D''<BR>
[0.116]Driver Version=3D'08.03.0300,200809260001' linking 1400 static Multi=
thread library<BR>
[0.123]Global Options: fetch=3D100, socket=3D4096, unknown_sizes=3D2, max_v=
archar_size=3D255, max_longvarchar_size=3D8190<BR>
[0.131]            &=
nbsp;   disable_optimizer=3D0, ksqo=3D1, unique_index=3D1, u=
se_declarefetch=3D0<BR>
[0.133]            &=
nbsp;   text_as_longvarchar=3D1, unknowns_as_longvarchar=3D0=
, bools_as_char=3D1 NAMEDATALEN=3D64<BR>
[0.136]            &=
nbsp;   extra_systable_prefixes=3D'dd_;', conn_settings=3D''=
conn_encoding=3D''<BR>
[0.544]    [ PostgreSQL version string =3D '8.3.4' ]<BR>
[0.545]    [ PostgreSQL version number =3D '8.3' ]<BR>
[0.565]conn=3D02E72C78, query=3D'select oid, typbasetype from pg_type where=
typname =3D 'lo''<BR>
[0.586]    [ fetched 0 rows ]<BR>
[0.601]    [ Large Object oid =3D -999 ]<BR>
[0.602]    [ Client encoding =3D 'UTF8' (code =3D 6) ]<BR>
[0.613]conn=3D02E72C78, PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL Log;DA=
TABASE=3Dmuna;SERVER=3Dlocalhost;PORT=3D5432;UID=3Dclient;PW D=3Dxxxxxx;SSLm=
ode=3Ddisable;ReadOnly=3D0;Protocol=3D7.4-1;FakeOidIndex=3D0 ;ShowOidColumn=
=3D0;RowVersioning=3D0;ShowSystemTables=3D0;ConnSettings=3D; Fetch=3D100;Soc=
ket=3D4096;UnknownSizes=3D2;MaxVarcharSize=3D255;MaxLongVarc harSize=3D8190;=
Debug=3D1;CommLog=3D1;Optimizer=3D0;Ksqo=3D1;UseDeclareFetch =3D0;TextAsLong=
Varchar=3D1;UnknownsAsLongVarchar=3D0;BoolsAsChar=3D1;Parse= 3D0;CancelAsFre=
eStmt=3D0;ExtraSysTablePrefixes=3Ddd_;;LFConversion=3D1;Upda tableCursors=3D=
1;DisallowPremature=3D0;TrueIsMinus1=3D0;BI=3D0;ByteaAsLongV arBinary=3D1;Us=
eServerSidePrepare=3D0;LowerCaseIdentifier=3D0;XaOpt=3D1'<BR>
[15.534]conn=3D02E72C78, query=3D'select count(*) from az001.doc101 where (=
code,riga)=3D(1,1)<BR>
'<BR>
[15.552]    [ fetched 1 rows ]<BR>
[15.608]conn=3D02E72C78, query=3D'show max_identifier_length'<BR>
[15.619]    [ fetched 1 rows ]<BR>
[15.660]STATEMENT ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D30=
, errmsg=3D'this request may be for MS SQL Server'<BR>
[15.663]            =
     ---------------------------------------------=
---------------<BR>
[15.664]            =
     hdbc=3D02E72C78, stmt=3D02E77808, result=3D02=
E70EA0<BR>
[15.665]            =
     prepare=3D0, internal=3D0<BR>
[15.666]            =
     bindings=3D02E791E8, bindings_allocated=3D1<B=
R>
[15.667]            =
     parameters=3D00000000, parameters_allocated=
=3D0<BR>
[15.668]            =
     statement_type=3D0, statement=3D'select count=
(*) from az001.doc101 where (code,riga)=3D(1,1)<BR>
'<BR>
[15.670]            =
     stmt_with_params=3D'select count(*) from az00=
1.doc101 where (code,riga)=3D(1,1)<BR>
'<BR>
[15.671]            =
     data_at_exec=3D-1, current_exec_param=3D-1, p=
ut_data=3D0<BR>
[15.672]            =
     currTuple=3D-1, current_col=3D-1, lobj_fd=3D-=
1<BR>
[15.673]            =
     maxRows=3D0, rowset_size=3D1, keyset_size=3D0=
, cursor_type=3D0, scroll_concurrency=3D1<BR>
[15.674]            =
     cursor_name=3D'SQL_CUR02E77808'<BR>
[15.675]            =
     ----------------QResult Info ----------------=
---------------<BR>
[15.677]            =
     fields=3D02E77BA8, backend_tuples=3D02E78E70,=
tupleField=3D48729712, conn=3D02E72C78<BR>
[15.678]            =
     fetch_count=3D0, num_total_rows=3D1, num_fiel=
ds=3D1, cursor=3D'(NULL)'<BR>
[15.679]            =
     message=3D'(NULL)', command=3D'SELECT', notic=
e=3D'(NULL)'<BR>
[15.680]            =
     status=3D100, inTuples=3D0<BR>
[15.681]CONN ERROR: func=3DPGAPI_ColAttributes, desc=3D'', errnum=3D0, errm=
sg=3D'(NULL)'<BR>
[15.683]            =
------------------------------------------------------------<BR>
[15.685]            =
henv=3D02E72C38, conn=3D02E72C78, status=3D1, num_stmts=3D16<BR>
[15.687]            =
sock=3D02E70A08, stmts=3D02E70AE0, lobj_type=3D-999<BR>
[15.688]            =
---------------- Socket Info -------------------------------<BR>
[15.690]            =
socket=3D552, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'<BR>
[15.692]            =
buffer_in=3D48715736, buffer_out=3D48719856<BR>
[15.692]            =
buffer_filled_in=3D76, buffer_filled_out=3D0, buffer_read_in=3D76<BR>
[15.735]CONN ERROR: func=3DSQLNativeSqlW, desc=3D'', errnum=3D-2, errmsg=3D=
'Sql string too large'<BR>
[15.737]            =
------------------------------------------------------------<BR>
[15.738]            =
henv=3D02E72C38, conn=3D02E72C78, status=3D1, num_stmts=3D16<BR>
[15.739]            =
sock=3D02E70A08, stmts=3D02E70AE0, lobj_type=3D-999<BR>
[15.740]            =
---------------- Socket Info -------------------------------<BR>
[15.741]            =
socket=3D552, reverse=3D0, errornumber=3D0, errormsg=3D'(NULL)'<BR>
[15.743]            =
buffer_in=3D48715736, buffer_out=3D48719856<BR>
[15.743]            =
buffer_filled_in=3D76, buffer_filled_out=3D0, buffer_read_in=3D76<BR>
[15.772]conn=3D02E72C78, query=3D'SELECT * FROM az001.doc101'<BR>
<BR>
<BR>
Thanks in advance, I apologize for my poor english.<BR>
<BR>
Regards,<BR>
<BR>
Moreno Dissegna<BR>
Developer<BR>
S.A. Software S.r.l.<BR>
<HR ALIGN=3DCENTER SIZE=3D"3" WIDTH=3D"100%">Scrivi, parla e gioca con i tu=
oi amici! Scarica Messenger 2009! <<a href=3D"http://messenger.it/gioca.=
aspx">http://messenger.it/gioca.aspx</a>> <BR>
</SPAN></FONT></FONT></BLOCKQUOTE>
</BODY>
</HTML>


--_000_C6419E611F0ksellgreenplumcom_--
Ken Sell [ Di, 26 Mai 2009 22:25 ] [ ID #2002821 ]

Re: Show max_identifier_length causes heavy query execution

Moreno D. wrote:
> I noticed that after executing a simple query that takes few
> milliseconds, the odbc driver executes another query which
> takes about 30 seconds to execute, because it scans a large table.
>
[...]
>
> Then the driver executes the heavy query "SELECT * FROM
> az001.doc101", which retrieves about 1.5 million rows.
>
[...]
>
> and this is the entire log file:
>
[...]
> [0.613]conn=3D02E72C78,
> PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL
> Log;DATABASE=3Dmuna;SERVER=3Dlocalhost;PORT=3D5432;UID=3Dcli ent;PWD=3Dxx
> xxxx;SSLmode=3Ddisable;ReadOnly=3D0;Protocol=3D7.4-1;FakeOid Index=3D0;
> ShowOidColumn=3D0;RowVersioning=3D0;ShowSystemTables=3D0;Con nSetting
> s=3D;Fetch=3D100;Socket=3D4096;UnknownSizes=3D2;MaxVarcharSi ze=3D255;Max
> LongVarcharSize=3D8190;Debug=3D1;CommLog=3D1;Optimizer=3D0;K sqo=3D1;UseD
> eclareFetch=3D0;TextAsLongVarchar=3D1;UnknownsAsLongVarchar= 3D0;Bool
> sAsChar=3D1;Parse=3D0;CancelAsFreeStmt=3D0;ExtraSysTablePref ixes=3Ddd_
> ;;LFConversion=3D1;UpdatableCursors=3D1;DisallowPremature=3D 0;TrueIs
> Minus1=3D0;BI=3D0;ByteaAsLongVarBinary=3D1;UseServerSidePrep are=3D0;Lo
> werCaseIdentifier=3D0;XaOpt=3D1'

Without the ODBC statements it is difficult to say something conclusive,
but it *might* be that you have the same problem I had some time ago.

I see that you set "Parse=3D0" in your connection options.
This will result in the ODBC driver executing "SELECT *"-Statements
when it needs to get a column description.

If that is the cause of your problem, then setting "Parse=3D1"
will fix it.

In ODBC Administrator on Windows, this option is called "Parse Statements"
and can be found in the advanced options page 1 (Button "Datasource").

Yours,
Laurenz Albe

--
Sent via pgsql-odbc mailing list (pgsql-odbc [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
Albe Laurenz [ Mi, 27 Mai 2009 09:16 ] [ ID #2002944 ]

Re: Show max_identifier_length causes heavy query execution

>If that is the cause of your problem, then setting "Parse=3D1"
>will fix it.
>
>In ODBC Administrator on Windows, this option is called "Parse Statements"
>and can be found in the advanced options page 1 (Button "Datasource").

Thank you Laurenz, setting "Parse=3D1" solved my problem!
Anyway, another problem appeared at another point in the application, i thi=
nk this is the reason why that flag was turned off.
I simplified the query that gives the error, and obtained this :

SELECT 1 as prog UNION SELECT code from aaa; --This one gives error

where aaa is a previously created table (If I create the table in the same =
statement, I don't get the error) :

create table aaa(
code integer -- i tried also with character varying, it's the same
);

If I write the two select in reverse order it works

SELECT code as prog from aaa UNION SELECT 1; --This one works

>Without the ODBC statements it is difficult to say something conclusive,

I attach below the log file, but I don't know what are the "ODBC statements=
"...Is it the "mylog" file? I'm using ADO components to connect to the data=
base, so I don't know very much about ODBC, I'm sorry..

I analized the mylog in both cases and noticed this difference:

(This is the correct one)
[2956-2.138]parse_statement: entering...
[2956-2.138]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'SELECT', ptr=3D'code as prog from aaa UNION SELECT 1;
'
[2956-2.140]SELECT
[2956-2.140]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'code', ptr=3D'as prog from aaa UNION SELECT 1;
'
[2956-2.142]blevel=3D0 btoken=3DSELECT in_dot=3D0 in_field=3D0 tbname=3D
[2956-2.143]reallocing at nfld=3D0
[2956-2.144]got field=3D'code', dot=3D'(null)'
[2956-2.144]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'as', ptr=3D'prog from aaa UNION SELECT 1;
'
[2956-2.146]blevel=3D0 btoken=3Dcode in_dot=3D0 in_field=3D1 tbname=3D
[2956-2.147]got AS
[2956-2.147]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'prog', ptr=3D'from aaa UNION SELECT 1;
'
[2956-2.149]blevel=3D0 btoken=3Das in_dot=3D0 in_field=3D1 tbname=3D
[2956-2.149]alias for field 'code' is 'prog'
[2956-2.150]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'from', ptr=3D'aaa UNION SELECT 1;
'
[2956-2.152]First [2956-2.152]FROM
[2956-2.152]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'aaa', ptr=3D'UNION SELECT 1;
'
[2956-2.153]got table =3D 'aaa'
[2956-2.154]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'UNION', ptr=3D'SELECT 1;
'
[2956-2.155]UNION... <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<=
<<<<<<

(And this is the one that gives error)
[3244-1.937]parse_statement: entering...
[3244-1.937]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'SELECT', ptr=3D'1 as prog UNION SELECT code from aaa;
'
[3244-1.939]SELECT
[3244-1.939]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D1, delim=3D' ', =
token=3D'1', ptr=3D'as prog UNION SELECT code from aaa;
'
[3244-1.941]blevel=3D0 btoken=3DSELECT in_dot=3D0 in_field=3D0 tbname=3D
[3244-1.942]reallocing at nfld=3D0
[3244-1.942]**** got numeric: nfld =3D 0
[3244-1.943]got field=3D'(null)', dot=3D'(null)'
[3244-1.944]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'as', ptr=3D'prog UNION SELECT code from aaa;
'
[3244-1.945]blevel=3D0 btoken=3D1 in_dot=3D0 in_field=3D1 tbname=3D
[3244-1.946]got AS
[3244-1.946]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'prog', ptr=3D'UNION SELECT code from aaa;
'
[3244-1.948]blevel=3D0 btoken=3Das in_dot=3D0 in_field=3D1 tbname=3D
[3244-1.948]alias for field '(null)' is 'prog'
[3244-1.949]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'UNION', ptr=3D'SELECT code from aaa;
'
[3244-1.951]blevel=3D0 btoken=3Dprog in_dot=3D0 in_field=3D0 tbname=3Dprog=

[3244-1.952]got field=3D'UNION', dot=3D'(null)' <<<<<<<<<<<<<<<<<<<<<<<<<<<=
<<<<<<<<<<<
[3244-1.953]unquoted=3D1, quote=3D0, dquote=3D0, numeric=3D0, delim=3D' ', =
token=3D'SELECT', ptr=3D'code from aaa;




This is psqlodbc_2008.log:
[0.007]Driver Version=3D'08.03.0400,200811070001' linking 1400 static Multi=
thread library
[0.015]Global Options: fetch=3D100, socket=3D4096, unknown_sizes=3D2, max_v=
archar_size=3D255, max_longvarchar_size=3D8190
[0.018] disable_optimizer=3D0, ksqo=3D1, unique_index=3D1, u=
se_declarefetch=3D0
[0.021] text_as_longvarchar=3D1, unknowns_as_longvarchar=3D0=
, bools_as_char=3D1 NAMEDATALEN=3D64
[0.025] extra_systable_prefixes=3D'dd_;', conn_settings=3D''=
conn_encoding=3D''
[0.104] [ PostgreSQL version string =3D '8.3.4' ]
[0.106] [ PostgreSQL version number =3D '8.3' ]
[0.121]conn=3D031C2470, query=3D'select oid, typbasetype from pg_type where=
typname =3D 'lo''
[0.139] [ fetched 0 rows ]
[0.148] [ Large Object oid =3D -999 ]
[0.150] [ Client encoding =3D 'UTF8' (code =3D 6) ]
[0.161]conn=3D031C2470, PGAPI_DriverConnect(out)=3D'DSN=3DPostgreSQL Log;DA=
TABASE=3Dmuna;SERVER=3Dlocalhost;PORT=3D5432;UID=3Dclient;PW D=3Dxxxxxx;SSLm=
ode=3Ddisable;ReadOnly=3D0;Protocol=3D7.4-1;FakeOidIndex=3D0 ;ShowOidColumn=
=3D0;RowVersioning=3D0;ShowSystemTables=3D0;ConnSettings=3D; Fetch=3D100;Soc=
ket=3D4096;UnknownSizes=3D2;MaxVarcharSize=3D255;MaxLongVarc harSize=3D8190;=
Debug=3D1;CommLog=3D1;Optimizer=3D0;Ksqo=3D1;UseDeclareFetch =3D0;TextAsLong=
Varchar=3D1;UnknownsAsLongVarchar=3D0;BoolsAsChar=3D1;Parse= 3D1;CancelAsFre=
eStmt=3D0;ExtraSysTablePrefixes=3Ddd_;;LFConversion=3D1;Upda tableCursors=3D=
1;DisallowPremature=3D0;TrueIsMinus1=3D0;BI=3D0;ByteaAsLongV arBinary=3D1;Us=
eServerSidePrepare=3D0;LowerCaseIdentifier=3D0;XaOpt=3D1'
[1.909]conn=3D031C2470, query=3D'SELECT 1 as prog UNION SELECT code from =
aaa;
'
[1.922] [ fetched 1 rows ]
[1.971]conn=3D031C2470, query=3D'select current_schema()'
[1.989] [ fetched 1 rows ]
[2.003]conn=3D031C2470, query=3D'select nspname from pg_namespace n, pg_cla=
ss c where c.relnamespace=3Dn.oid and c.oid=3D'"aaa"'::regclass'
[2.024] [ fetched 1 rows ]
[2.095]conn=3D031C2470, query=3D'select n.nspname, c.relname, a.attname, a.=
atttypid, t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull, c.relha=
srules, c.relkind, c.oid, d.adsrc from (((pg_catalog.pg_class c inner join =
pg_catalog.pg_namespace n on n.oid =3D c.relnamespace and c.relname =3D E'a=
aa' and n.nspname =3D E'public') inner join pg_catalog.pg_attribute a on (n=
ot a.attisdropped) and a.attnum> 0 and a.attrelid =3D c.oid) inner join pg_=
catalog.pg_type t on t.oid =3D a.atttypid) left outer join pg_attrdef d on =
a.atthasdef and d.adrelid =3D a.attrelid and d.adnum =3D a.attnum order by =
n.nspname, c.relname, attnum'
[2.152] [ fetched 1 rows ]
[2.289]PGAPI_Columns: table=3D'aaa',field_name=3D'code',type=3D23,name=3D'i=
nt4'
[2.393]STATEMENT ERROR: func=3DPGAPI_DescribeCol, desc=3D'Col#=3D1, #Cols=
=3D1,1 keys=3D2', errnum=3D13, errmsg=3D'Invalid column number in DescribeC=
ol.'
[2.397] ---------------------------------------------------=
---------
[2.398] hdbc=3D031C2470, stmt=3D031C6FD0, result=3D031C72E8
[2.399] prepare=3D0, internal=3D0
[2.400] bindings=3D031C89E0, bindings_allocated=3D1
[2.401] parameters=3D00000000, parameters_allocated=3D0
[2.402] statement_type=3D0, statement=3D'SELECT 1 as prog =
UNION SELECT code from aaa;
'
[2.403] stmt_with_params=3D'SELECT 1 as prog UNION SELECT=
code from aaa;
'
[2.405] data_at_exec=3D-1, current_exec_param=3D-1, put_dat=
a=3D0
[2.406] currTuple=3D-1, current_col=3D-1, lobj_fd=3D-1
[2.406] maxRows=3D0, rowset_size=3D1, keyset_size=3D0, curs=
or_type=3D0, scroll_concurrency=3D1
[2.407] cursor_name=3D'SQL_CUR031C6FD0'
[2.408] ----------------QResult Info ----------------------=
---------
[2.409] fields=3D031C7398, backend_tuples=3D031C8698, tuple=
Field=3D52201112, conn=3D031C2470
[2.411] fetch_count=3D0, num_total_rows=3D1, num_fields=3D1=
, cursor=3D'(NULL)'
[2.412] message=3D'(NULL)', command=3D'SELECT', notice=3D'(=
NULL)'
[2.414] status=3D100, inTuples=3D0
[2.415]CONN ERROR: func=3DPGAPI_DescribeCol, desc=3D'Col#=3D1, #Cols=3D1,1 =
keys=3D2', errnum=3D0, errmsg=3D'(NULL)'
[2.418] --------------------------------------------------------=
----
[2.419] henv=3D031C0A70, conn=3D031C2470, status=3D1, num_stmts=
=3D16
[2.420] sock=3D031C0AA0, stmts=3D031C0B68, lobj_type=3D-999
[2.421] ---------------- Socket Info ---------------------------=
----
[2.422] socket=3D552, reverse=3D0, errornumber=3D0, errormsg=3D'=
(NULL)'
[2.423] buffer_in=3D52187072, buffer_out=3D52191176
[2.424] buffer_filled_in=3D456, buffer_filled_out=3D0, buffer_re=
ad_in=3D456
[3.990]conn=3D031C2470, PGAPI_Disconnect

Regards,

Moreno Dissegna
Developer
S.A. Software S.r.l.






____________________________________________________________ _____
Pi=F9 di 100 Emoticon gratis per il tuo Messenger!
http://intrattenimento.it.msn.com/emoticon
--
Sent via pgsql-odbc mailing list (pgsql-odbc [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc
moreno.d [ Do, 28 Mai 2009 15:42 ] [ ID #2003096 ]

Re: Show max_identifier_length causes heavy query execution

This is a multi-part message in MIME format.
--------------070101080508090402080607
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Moreno D. wrote:
>> If that is the cause of your problem, then setting "Parse=1"
>> will fix it.
>>
>> In ODBC Administrator on Windows, this option is called "Parse Statements"
>> and can be found in the advanced options page 1 (Button "Datasource").
>
> Thank you Laurenz, setting "Parse=1" solved my problem!
> Anyway, another problem appeared at another point in the application, i think this is the reason why that flag was turned off.

Please look at the attached documentation especially about Parse
Statements, ServerSide Prepare or Disallow Premature options.

regards,
Hiroshi Inoue

--------------070101080508090402080607
Content-Type: text/html; charset=US-ASCII;
name="config.html"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="config.html"

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=US-ASCII">
<title>psqlODBC Configuration Options</title>
</HEAD>

<body bgcolor="#ffffff" text="#000000" link="#ff0000" vlink="#a00000" alink="#0000ff">

<h1>psqlODBC Configuration Options</h1>

<h2>Advanced Options 1/2 Dialog Box</h2>

<ul>
<li><b>DEFAULTS:</b> Press to this button restore the normal defaults for the
settings described below.
 </li>

<li><b>Disable Genetic Optimizer:</b> Automatically
turns off the backend genetic optimizer at connection time. This
is a convenience feature rather than having to type it in the connect settings.
This feature was added when we noticed the backend seemed to have
big problems optimizing some queries.
 </li>

<li><b>KSQO (Keyset Query Optimization):</b>
<b><em>Deprecated for 7.1+ servers.</em></b> Check this option when connecting 7.0- servers and the application seems to be suffering from the following kind of queries:<br><br>

<code>select...where (a = 1 AND b = 1 AND c = 1) OR (a=1 AND b=1 AND
c = 2)...</code><br> </li>

<li><b>Recognize Unique Indexes:</b>
Check this option.
 </li>

<li><b>Use Declare/Fetch:</b> If
true, the driver automatically uses declare cursor/fetch to handle
SELECT statements and keeps 100 rows in a cache. This is mostly a
great advantage, especially if you are only interested in reading and not
updating. It results in the driver not sucking down lots of memory
to buffer the entire result set. If set to false, cursors will not
be used and the driver will retrieve the entire result set. For very
large tables, this is very inefficient and may use up all the Windows memory/resources.
However, it may handle updates better since the tables are not kept open,
as they are when using cursors. This was the style of the old podbc32
driver. However, the behavior of the memory allocation is much improved
so even when not using cursors, performance should at least be better than
the old podbc32.
 </li>

<li><b>CommLog (C:\psqlodbc_xxxx.log):</b>
Log communications to/from the backend to that file. This is good
for debugging problems.
 </li>

<li><b>Parse Statements:</b> Tell the driver how to gather the information about result columns of queries. See also <em>Disallow Premature</em> and <em>ServerSide Prepare</em> options.<br>
The driver checks this option first. If disabled then it checks the Server Side Prepare option. If disabled also it checks the Disallow Premature option.<br>
If neither of them is specified the driver would execute the prepared statement prematurely when the application inquires the result columns' info.<br><br>

If this option is enabled,
the driver will parse an SQL query statement to identify the columns and
tables and gather statistics about them such as precision, nullability,
aliases, etc. It then reports this information in SQLDescribeCol,
SQLColAttributes, and SQLNumResultCols. <b>Prior to PostgreSQL 6.4,
this was the only accurate way of getting information on precision from
a query result.</b><br><br>

If the parser can not deal with a column (because it is a function
or expression, etc.), it will fallback to executing the statement which
is the old style of getting the info. The parser is fairly
sophisticated and can handle many things such as column and table aliases,
quoted identifiers, literals, joins, cross-products, etc. It can
correctly identify a function or expression column, regardless of the complexity,
but it does not attempt to determine the data type or precision of these
columns.
 </li>

<li><b>Cancel as FreeStmt:</b>

 </li>

<li><b>MyLog (C:\mylog_xxxx.log):</b>
Log debug messages to that file. This is good
for debugging problems with the driver.
 </li>

<li><b>Unknown Sizes: </b>This controls
what SQLDescribeCol and SQLColAttributes will return as to precision for
character data types (varchar, text, and unknown) in a result set when
the precision is unknown. <b>This was more of a workaround for pre-6.4
versions of PostgreSQL not being able to return the defined column width
of the varchar data type</b>.<br><br>

<ul>

<li><i>Maximum</i>: Always
return the maximum precision of the data type.</li>

<li><i>Dont Know</i>: Return "Don't Know"
value and let application decide.</li>

<li><i>Longest</i>: Return
the longest string length of the column of any row. Beware of this
setting when using cursors because the cache size may not be a good representation
of the longest column in the cache.</li>

<br>

<i>MS Access</i>: Seems to handle <i>Maximum</i> setting ok, as well as all the others.<br>
<i>Borland</i>: If sizes are large and lots of columns, Borland may crash badly (it doesn't seem to handle memory allocation well)
if using <i>Maximum</i> size.

</ul><br>

<li><b>Data Type Options:</b> affects how some data types are mapped:
 </li>

<ul>

<li><i>Text as LongVarChar</i>:
PostgreSQL TEXT type is mapped to SQLLongVarchar, otherwise SQLVarchar.</li>

<li><i>Unknowns as LongVarChar</i>: Unknown types (arrays, etc) are mapped to SQLLongVarChar, otherwise SQLVarchar</li>

<li><i>Bools as Char</i>: Bools are mapped to SQL_CHAR, otherwise to SQL_BIT.</li>

</ul><br>

<li><b>Max Varchar</b> The maximum
precision of the Varchar and BPChar(char[x]) types. The default is 254
which actually means 255 because of the null terminator. Note, if
you set this value higher than 254, Access will not let you index on varchar
columns!
 </li>

<li><b>Cache Size:</b>When using
cursors, this is the row size of the tuple cache. If not using cursors,
this is how many tuples to allocate memory for at any given time.
The default is 100 rows for either case.
 </li>

<li><b>Max LongVarChar:</b> The maximum
precision of the LongVarChar type. The default is 4094 which actually
means 4095 with the null terminator. You can even specify (-4) for
this size, which is the odbc SQL_NO_TOTAL value.
 </li>

<li><b>SysTable Prefixes:</b> The
additional prefixes of table names to regard as System Tables. The
driver already treats names that begin with "pg_" as system tables.
Here you can add additional ones, such as data dictionary tables (dd_).
Separate each prefix with a semicolon (;)
 </li>

</ul>

<h2>Advanced Options 2/2 Dialog Box</h2>

<ul>

<li><b>ReadOnly:</b> Whether the
datasource will allow updates.
 </li>

<li><b>Show System Tables:</b> The
driver will treat system tables as regular tables in SQLTables. This
is good for Access so you can see system tables.
 </li>

<li><b>LF <-> CR/LF conversion:</b> Convert Unix style line endings to
DOS style.
 </li>

<li><b>Updateable Cursors:</b> Enable updateable cursor emulation in the
driver.
 </li>

<li><b>Bytea as LO:</b> Allow the use of bytea columns for Large Objects.

 </li>

<li><b>Row Versioning:</b> Allows
applications to detect whether data has been modified by other users while
you are attempting to update a row. It also speeds the update process
since every single column does not need to be specified in the where clause
to update a row. The driver uses the "xmin" system field of PostgreSQL
to allow for row versioning. Microsoft products seem to use this
option well. See the <a "http://psqlodbc.projects.postgresql.org/faq.html">faq</a>
for details on what you need to do to your database to allow for the row
versioning feature to be used.
 </li>

<li><b>Disallow Premature:</b>
Mainly for 7.1 to 7.3 servers. <b><em>Server side prepare</em></b> is a more preferable option for 7.4+ servers.<br>
Tell the driver how to gather the information about result columns. See also <em>Parse Staements</em> and <em>Server Side Prepare</em> options.<br>
This is an option to compensate for the lack of a server's <em>Prepare</em> functionality.
For example, (Middleware) applications issue the following ODBC API calls.<br><br>

SQLPreapare(hstmt, "select ...", ..)<br><br>

In most cases they have to know how many fields, what kind
of fields they would return and so they would issue<br><br>

SQLNumResultCols and/or <br>
SQLDescribeCols/SQLColAttribute etc.<br><br>

The problem is how the psqlODBC driver answers the inquiry. PostgreSQL hadn't
provided the <em>Prepare</em> functionality until 7.4 and we couldn't ask the backend about
it directly.

When using Disallow Premature, the driver will get the column info as follows:<br><br>
<i>
   begin;(unless in a transaction)<br>
   declare cursor .. for select ...<br>
   fetch backward in ..<br>
   close ..<br><br>
</i>
The driver gets the field info using the fetch backward's result. The fetch backward
command returns no row but returns the field info. Though the command is expected to be returned immediately it isn't true for 7.0- servers unfortunately.
The 7.1 or later servers <b>do</b> seem to return from the fetch backward command
immediately.
 </li>

<li><b>True is -1:</b> Represent TRUE as -1 for compatibility with some applications.

 </li>

<li><b>Server side prepare:</b> Applicable for 7.3+ servers and <em>recommended for 7.4+.</em>
 
(7.4+) Tell the driver how to gather the information about result columns. See also <em>Parse Statement</em> and <em>Disallow Premature</em> options.<br>        By using extended query protocol the driver replies to the inquiry correctly and effectively.<br> 
(7.4+) By using extended query protocol the driver replies to the inquiry for the information of parameters.<br> 
(7.3+) When using prepared statements, prepare them on the server rather than in the driver. This can give a slight performance advantage as the server<br>
        doesn't need to re-parse the statement each time it is used.
 </li>

<li><b>Int8 As:</b> Define what datatype to report int8 columns as.
 </li>

<li><b>Extra Opts:</b> combination of the following bits.
<br> 
0x1: Force the output of short-length formatted connection string. Check this bit when you use MFC CDatabase class.
 
0x2: Fake MS SQL Server so that MS Access recognizes PostgreSQL's serial type as AutoNumber type.
 
0x4: Reply ANSI (not Unicode) char types for the inquiries from applications. Try to check this bit when your applications don't seem to be good at handling Unicode data.
 </li>

<li><b>Protocol:</b> Note that when using SSL connections this setting is ignored.
 

<ul>
<li><i>6.2:</i> Forces driver to
use PostgreSQL 6.2(V0) protocol, which had different byte ordering, protocol,
and other semantics.
 

<li><i>6.3</i>: Use the 6.3(V1) protocol. This is compatible
with both V1(6.3) and V2(6.4 to 7.3) backends.
 </li>

<li><i>6.4+</i>: Use the 6.4(V2) protocol. This is only compatible
with 6.4 and higher backends.
 </li>

<li><i>7.4+</i>: Use the 7.4(V3) protocol. This is only compatible
with 7.4 and higher backends.
 </li>
</ul></li>

<li><b>Level of rollback on errors:</b> Specifies what to rollback should an
error occur.
 

<ul>
<li><i>Nop(0):</i> Don't rollback anything and let the application handle the
error.
 </li>

<li><i>Transaction(1):</i> Rollback the entire transaction.
 </li>

<li><i>Statement(2):</i> Rollback the statement.
 </li>
<br>
<b>Notes in a setup: This specification is set up with a PROTOCOL option parameter.</b><br><br>
PROTOCOL=[6.2|6.3|6.4|7.4][-(0|1|2)]<br>
default value is a sentence unit (it is a transaction unit before 8.0).<br>
<br>

</ul></li>


<li><b>OID Options:</b>
 

<ul>
<li><i>Show Column: </i> Includes the OID
in SQLColumns. This is good for using as a unique identifier to update
records if no good key exists OR if the key has many parts, which
blows up the backend.
 </li>

<li><i>Fake Index: </i> This option
fakes a unique index on OID. This is useful when there is not a real
unique index on OID and for apps which can't ask what the unique identifier
should be (i.e, Access 2.0).
 </li>
</ul></li>

<li><b>Connect Settings:</b> The
driver sends these commands to the backend upon a successful connection. 
It sends these settings AFTER it sends the driver "Connect Settings".
Use a semi-colon (;) to separate commands. This can now handle any
query, even if it returns results. The results will be thrown away
however!
 </li>
</ul>

<h2>Global settings Dialog Box</h2>

<p>This dialog allows you to specify pre-connection/default logging
options</p>

<ul>

<li><b>CommLog (C:\psqlodbc_xxxx.log - Communications log):</b>
Log communications to/from the backend to that file. This is good
for debugging problems.
 </li>

<li><b>MyLog (C:\mylog_xxxx.log - Detailed debug output):</b>
Log debug messages to that file. This is good
for debugging problems with the driver.
 </li>

<li><b>MSDTCLog (C:\pgdtclog\mylog_xxxx.log - MSDTC debug output):</b>
Log debug messages to that file. This is good
for debugging problems with the MSDTC.
 </li>

<li><b>Specification of the holder for log outputs:</b>
Adjustment of write permission.
 </li>

</ul>

<h2>Manage DSN Dialog Box</h2>

<p>This dialog allows you to select which PostgreSQL ODBC driver
to use for this connection. Note that this may not work with third
party drivers.</p>

<h2>How to specify as a connection option</h2>

<p>There is a method of specifying a connection option in a keyword strings.</p>
<p>Example:VBA</p>
<ul><li><b>
myConn = "ODBC;DRIVER={PostgreSQL};" & serverConn & _
"A0=0;A1=6.4;A2=0;A3=0;A4=0;A5=0;A6=;A7=100;A8=4096;A9=0;" & _
"B0=254;B1=8190;B2=0;B3=0;B4=1;B5=1;B6=0;B7=1;B8=0;B9=1;" & _
"C0=0;C1=0;C2=dd_"
</b></li>
</ul>
<p>Please refer to a keyword list for details. </p>

</body>
</html>

--------------070101080508090402080607
Content-Type: text/plain
Content-Disposition: inline
MIME-Version: 1.0
Content-Transfer-Encoding: quoted-printable


--
Sent via pgsql-odbc mailing list (pgsql-odbc [at] postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

--------------070101080508090402080607--
Hiroshi Inoue [ Fr, 29 Mai 2009 02:04 ] [ ID #2003306 ]

Re: Show max_identifier_length causes heavy query execution

--_57ede989-662c-4577-b81c-63855270f8c6_
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable


>Please look at the attached documentation especially about Parse
> Statements=2C ServerSide Prepare or Disallow Premature options.
Thank you Hiroshi=2C
I solved my problems setting ServerSide Prepare=3D1=2C Parse statements=3D0=
and Disallow premature=3D0.
Thanks for the documentation=2C the next time I have problems I will read i=
t carefully.
I would also thank Laurenz and Ken for the help.

Moreno Dissegna
Developer
S.A. Software S.r.l.

____________________________________________________________ _____
Hai voglia di divertirti? Scarica i nuovissimi gadget di Messenger!
http://messenger.it/home_gadget.aspx=

--_57ede989-662c-4577-b81c-63855270f8c6_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<style>
..hmmessage P
{
margin:0px=3B
padding:0px
}
body.hmmessage
{
font-size: 10pt=3B
font-family:Verdana
}
</style>
</head>
<body class=3D'hmmessage'>
<pre>>=3BPlease look at the attached documentation especially about Parse=
<br>>=3B Statements=2C ServerSide Prepare or Disallow Premature options.=
<br></pre>Thank you Hiroshi=2C <br>I solved my problems setting ServerSide =
Prepare=3D1=2C Parse statements=3D0 and Disallow premature=3D0.<br>Thanks f=
or the documentation=2C the next time I have problems I will read it carefu=
lly.<br>I would also thank Laurenz and Ken for the help.<br><br><pre>Moreno=
Dissegna<br>Developer<br>S.A. Software S.r.l.</pre><br>
<hr />Persona=
lizza Messenger 2009. <a href=3D'http://messenger.it/funzioniPersonalizzazi=
one.aspx' target=3D'_new'>Scegli la grafica che ti rappresenta meglio!</a><=
/body>
</html>=

--_57ede989-662c-4577-b81c-63855270f8c6_--
moreno.d [ Sa, 06 Juni 2009 13:19 ] [ ID #2004114 ]
Datenbanken » gmane.comp.db.postgresql.odbc » Show max_identifier_length causes heavy query execution

Vorheriges Thema: ODBL windows has no drop down choices
Nächstes Thema: Unicode ODBC driver with support of SQLForeignKeys?