Bookmarks

Yahoo Gmail Google Facebook Delicious Twitter Reddit Stumpleupon Myspace Digg

Search queries

wwwxxx,nvif, why atm producer might be held liable for economic injury, wwwxxxy=ServiceLogin, w2ksp4.exe, WwwxxXdbf, procmail "FROM_MAILER" patch, Use of assignment to $[ is deprecated at /usr/local/sbin/apxs line 86. , wwwxxx vim, mysql closing table and opening table, 800c5000

Links

XODOX
Impressum

#1: Issues when using schema names with odbc

Posted on 2010-11-18 17:22:30 by michael.28.smith

--_000_806CB309AA19EE4F8F30EB5DF3E372B33B41580830EMV61UKRDdo ma_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

I think there is an issue with the following version of postgresql-odbc whe=
re I am unable to use schema names.

Using "isql " "help table_name" returns information about the column name=
s but "help schema.table_name returns nothing.

This assumes the identical tables are in public.table_name and schema.table=
_name

I actually come across this when using asterisk realtime - I was about to r=
aise this as an asterisk issue and came across this - which suggests it is =
actually an underlying odbc issue.

https://issues.asterisk.org/view.php?id=3D15963


Has this been seen before..?

Many Thanks

Mike

rpm -qa |grep odbc
postgresql-odbc-08.01.0200-3.1

rpm -qa |grep postgres
postgresql-server-8.1.11-1.el5_1.1
postgresql-libs-8.1.11-1.el5_1.1
postgresql-8.1.11-1.el5_1.1
postgresql-libs-8.1.11-1.el5_1.1
postgresql-odbc-08.01.0200-3.1

Asterisk 1.6.2.12,



Mike Smith
Voice & Multimedia Platform | BT Innovate & Design
Tel: +44 (0) 20 7876 8005
ClickDial Me<http://www.ibridge.bt.com/ClickDial/MakeCall?+442078768005>


--_000_806CB309AA19EE4F8F30EB5DF3E372B33B41580830EMV61UKRDdo ma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>
<meta http-equiv=3DContent-Type content=3D"text/html; charset=3Dus-ascii">
<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
span.EmailStyle17
{mso-style-type:personal-compose;
font-family:"Calibri","sans-serif";
color:windowtext;}
..MsoChpDefault
{mso-style-type:export-only;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
{page:WordSection1;}
-->
</style>
<!--[if gte mso 9]><xml>
<o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext=3D"edit">
<o:idmap v:ext=3D"edit" data=3D"1" />
</o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-GB link=3Dblue vlink=3Dpurple>

<div class=3DWordSection1>

<p class=3DMsoNormal>I think there is an issue with the following version o=
f
postgresql-odbc where I am unable to use schema names.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Using &#8220;isql &#8221; &nbsp;&#8220;help table_name=
&#8221;
&nbsp;returns information about the column names but &#8220;help
schema.table_name returns nothing.<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>This assumes the identical tables are in public.table_=
name
and schema.table_name<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>I actually come across this when using asterisk realti=
me
&#8211; I was about to raise this as an asterisk issue and came across this
&#8211; which suggests it is actually an underlying odbc issue.<o:p></o:p><=
/p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><a href=3D"https://issues.asterisk.org/view.php?id=3D1=
5963">https://issues.asterisk.org/view.php?id=3D15963</a><o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Has this been seen before..?<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Many Thanks<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Mike<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>rpm -qa |grep odbc<o:p></o:p></p>

<p class=3DMsoNormal>postgresql-odbc-08.01.0200-3.1<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>rpm -qa |grep postgres<o:p></o:p></p>

<p class=3DMsoNormal><span lang=3DES>postgresql-server-8.1.11-1.el5_1.1<o:p=
></o:p></span></p>

<p class=3DMsoNormal><span lang=3DES>postgresql-libs-8.1.11-1.el5_1.1<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span lang=3DES>postgresql-8.1.11-1.el5_1.1<o:p></o:p>=
</span></p>

<p class=3DMsoNormal><span lang=3DES>postgresql-libs-8.1.11-1.el5_1.1<o:p><=
/o:p></span></p>

<p class=3DMsoNormal><span lang=3DES>postgresql-odbc-08.01.0200-3.1<o:p></o=
:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal>Asterisk 1.6.2.12,<o:p></o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

<p class=3DMsoNormal><span style=3D'color:blue'><br>
</span><b><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Mike Smith</span></b><span style=3D'color:blue'><br>
</span><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Voice &amp; Multimedia Platform | BT Innovate &amp; Design</sp=
an><span
style=3D'color:blue'><br>
</span><span style=3D'font-size:7.5pt;font-family:"Arial","sans-serif";
color:black'>Tel: +44 (0) </span><span style=3D'font-size:7.5pt;font-family=
:"Arial","sans-serif"'>20&nbsp;7876&nbsp;8005<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:7.5pt;font-family:"Arial","sa=
ns-serif"'><a
href=3D"http://www.ibridge.bt.com/ClickDial/MakeCall?+442078 768005">ClickDi=
al Me</a><o:p></o:p></span></p>

<p class=3DMsoNormal><o:p>&nbsp;</o:p></p>

</div>

</body>

</html>

--_000_806CB309AA19EE4F8F30EB5DF3E372B33B41580830EMV61UKRDdo ma_--

Report this message

#2: Re: Issues when using schema names with odbc

Posted on 2010-11-20 03:33:01 by Hiroshi Inoue

(2010/11/19 1:22), michael.28.smith@bt.com wrote:
> I think there is an issue with the following version of postgresql-odbc
> where I am unable to use schema names.
>
> Using =93isql =94 =93help table_name=94 returns information about the c=
olumn
> names but =93help schema.table_name returns nothing.

ODBC doesn't handle schema_name.table_name type format.
For example the syntax of SQLColumns() is as follows.

SQLRETURN SQLColumns(
SQLHSTMT StatementHandle,
SQLCHAR * CatalogName,
SQLSMALLINT NameLength1,
SQLCHAR * SchemaName,
SQLSMALLINT NameLength2,
SQLCHAR * TableName,
SQLSMALLINT NameLength3,
SQLCHAR * ColumnName,
SQLSMALLINT NameLength4);

regards,
Hiroshi Inoue

> This assumes the identical tables are in public.table_name and
> schema.table_name
>
> I actually come across this when using asterisk realtime =96 I was abou=
t
> to raise this as an asterisk issue and came across this =96 which sugge=
sts
> it is actually an underlying odbc issue.
>
> https://issues.asterisk.org/view.php?id=3D15963
>
> Has this been seen before..?
>
> Many Thanks
>
> Mike
>
> rpm -qa |grep odbc
>
> postgresql-odbc-08.01.0200-3.1
>
> rpm -qa |grep postgres
>
> postgresql-server-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-odbc-08.01.0200-3.1
>
> Asterisk 1.6.2.12

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Report this message

#3: Re: Issues when using schema names with odbc

Posted on 2010-11-29 15:51:00 by michael.28.smith

Used a little test app to verify this and I get different results,

Assuming create schema test_schema;

create table public.test(
row1 int,
row2 text);

create table test_schema.test(
row_t_1 int,
row_t_2 text);

grant usage on schema test_schema to public;
grant select on public.test to public;
grant select on test_schema.test to public;

insert into public.test values (1,'public schema');
insert into test_schema.test values (2,'test schema');



The test app shows the following results....:


[root@winston scripts]# ./sqltest
SQLColumns Connection Test
Handles Allocated

Getting columns from test_schema.test
No data!

Getting all rows from test_schema.test
Row 0:1=3D2;2=3Dtest schema;

Getting columns from public.test
No data!

Getting all rows from public.test
Row 0:1=3D1;2=3Dpublic schema;

Getting columns from (null).test
Column 0: row
Column 1: row
Column 2: row
Column 3: row

Getting all rows from (null).test
Row 0:1=3D1;2=3Dpublic schema;


It shows that when using schema.table_name no column data is returned, but =
returns when not using a schema name.

Any other ideas?

Cheers


Mike Smith
Voice & Multimedia Platform | BT Innovate & Design
Tel: +44 (0) 20=A07876=A08005
ClickDial Me


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue@tpf.co.jp]=20
Sent: 20 November 2010 02:33
To: Smith,M,Michael,DLW C
Cc: pgsql-odbc@postgresql.org; Hindmarch,SJ,Stephen,DLW R
Subject: Re: [ODBC] Issues when using schema names with odbc

(2010/11/19 1:22), michael.28.smith@bt.com wrote:
> I think there is an issue with the following version of postgresql-odbc
> where I am unable to use schema names.
>
> Using "isql " "help table_name" returns information about the column
> names but "help schema.table_name returns nothing.

ODBC doesn't handle schema_name.table_name type format.
For example the syntax of SQLColumns() is as follows.

SQLRETURN SQLColumns(
SQLHSTMT StatementHandle,
SQLCHAR * CatalogName,
SQLSMALLINT NameLength1,
SQLCHAR * SchemaName,
SQLSMALLINT NameLength2,
SQLCHAR * TableName,
SQLSMALLINT NameLength3,
SQLCHAR * ColumnName,
SQLSMALLINT NameLength4);

regards,
Hiroshi Inoue

> This assumes the identical tables are in public.table_name and
> schema.table_name
>
> I actually come across this when using asterisk realtime - I was about
> to raise this as an asterisk issue and came across this - which suggests
> it is actually an underlying odbc issue.
>
> https://issues.asterisk.org/view.php?id=3D15963
>
> Has this been seen before..?
>
> Many Thanks
>
> Mike
>
> rpm -qa |grep odbc
>
> postgresql-odbc-08.01.0200-3.1
>
> rpm -qa |grep postgres
>
> postgresql-server-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-odbc-08.01.0200-3.1
>
> Asterisk 1.6.2.12

--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Report this message

#4: Re: Issues when using schema names with odbc

Posted on 2010-11-29 16:03:19 by michael.28.smith

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


Attaching test app source for reference.



Mike Smith
Voice & Multimedia Platform | BT Innovate & Design
Tel: +44 (0) 20=A07876=A08005
ClickDial Me


-----Original Message-----
From: Smith,M,Michael,DLW C=20
Sent: 29 November 2010 14:51
To: 'Hiroshi Inoue'
Cc: pgsql-odbc@postgresql.org; Hindmarch,SJ,Stephen,DLW R
Subject: RE: [ODBC] Issues when using schema names with odbc

Used a little test app to verify this and I get different results,

Assuming create schema test_schema;

create table public.test(
row1 int,
row2 text);

create table test_schema.test(
row_t_1 int,
row_t_2 text);

grant usage on schema test_schema to public;
grant select on public.test to public;
grant select on test_schema.test to public;

insert into public.test values (1,'public schema');
insert into test_schema.test values (2,'test schema');



The test app shows the following results....:


[root@winston scripts]# ./sqltest
SQLColumns Connection Test
Handles Allocated

Getting columns from test_schema.test
No data!

Getting all rows from test_schema.test
Row 0:1=3D2;2=3Dtest schema;

Getting columns from public.test
No data!

Getting all rows from public.test
Row 0:1=3D1;2=3Dpublic schema;

Getting columns from (null).test
Column 0: row
Column 1: row
Column 2: row
Column 3: row

Getting all rows from (null).test
Row 0:1=3D1;2=3Dpublic schema;


It shows that when using schema.table_name no column data is returned, but =
returns when not using a schema name.

Any other ideas?

Cheers


Mike Smith
Voice & Multimedia Platform | BT Innovate & Design
Tel: +44 (0) 20=A07876=A08005
ClickDial Me


-----Original Message-----
From: Hiroshi Inoue [mailto:inoue@tpf.co.jp]=20
Sent: 20 November 2010 02:33
To: Smith,M,Michael,DLW C
Cc: pgsql-odbc@postgresql.org; Hindmarch,SJ,Stephen,DLW R
Subject: Re: [ODBC] Issues when using schema names with odbc

(2010/11/19 1:22), michael.28.smith@bt.com wrote:
> I think there is an issue with the following version of postgresql-odbc
> where I am unable to use schema names.
>
> Using "isql " "help table_name" returns information about the column
> names but "help schema.table_name returns nothing.

ODBC doesn't handle schema_name.table_name type format.
For example the syntax of SQLColumns() is as follows.

SQLRETURN SQLColumns(
SQLHSTMT StatementHandle,
SQLCHAR * CatalogName,
SQLSMALLINT NameLength1,
SQLCHAR * SchemaName,
SQLSMALLINT NameLength2,
SQLCHAR * TableName,
SQLSMALLINT NameLength3,
SQLCHAR * ColumnName,
SQLSMALLINT NameLength4);

regards,
Hiroshi Inoue

> This assumes the identical tables are in public.table_name and
> schema.table_name
>
> I actually come across this when using asterisk realtime - I was about
> to raise this as an asterisk issue and came across this - which suggests
> it is actually an underlying odbc issue.
>
> https://issues.asterisk.org/view.php?id=3D15963
>
> Has this been seen before..?
>
> Many Thanks
>
> Mike
>
> rpm -qa |grep odbc
>
> postgresql-odbc-08.01.0200-3.1
>
> rpm -qa |grep postgres
>
> postgresql-server-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-8.1.11-1.el5_1.1
>
> postgresql-libs-8.1.11-1.el5_1.1
>
> postgresql-odbc-08.01.0200-3.1
>
> Asterisk 1.6.2.12

--_002_806CB309AA19EE4F8F30EB5DF3E372B33B5E635C4DEMV61UKRDdo ma_
Content-Type: text/plain; name="sqltest.c"
Content-Description: sqltest.c
Content-Disposition: attachment; filename="sqltest.c"; size=5607;
creation-date="Mon, 29 Nov 2010 15:02:29 GMT";
modification-date="Mon, 29 Nov 2010 15:02:29 GMT"
Content-Transfer-Encoding: base64

I2luY2x1ZGUgPHN0ZGFyZy5oPg0KI2luY2x1ZGUgPHN0ZGlvLmg+DQojaW5j
bHVkZSA8c3RkbGliLmg+DQojaW5jbHVkZSA8c3FsLmg+DQojaW5jbHVkZSA8
c3FsZXh0Lmg+DQojaW5jbHVkZSA8c3FsdHlwZXMuaD4NCg0KLyogU1FMIFRl
c3QuIFRlc3QgdGhlIFNRTENvbHVtbnMgZmVhdHVyZSBvZiBvZGJjIHRvIGNo
ZWNrIHRoYXQgc2NoZW1hcyBjYW4gYmUNCiAqIHVzZWQuDQogKiAkVVJMOiBo
dHRwczovL3N2bi5jb29sd29ybGQuYnQuY28udWsvc3ZuL3NqaC90cnVuay9z
Y3JpcHRzL3NxbHRlc3QuYyAkDQogKiAkQXV0aG9yOiBzamggJA0KICogJERh
dGU6IDIwMTAtMTEtMjkgMTA6NTY6MjEgKzAwMDAgKE1vbiwgMjkgTm92IDIw
MTApICQNCiAqICRSZXZpc2lvbjogMjY4ICQNCiAqDQogKiBDb3B5cmlnaHQg
QnJpdGlzaCBUZWxlY29tbXVuaWNhdGlvbnMgUExDIDIwMDkNCiAqDQogKi8N
Cg0KLyogVGhpcyBmdW5jdGlvbiBjb3VydGVzeSBvZiB0aGUgdW5peE9EQkMg
dHV0b3JpYWwgDQogKiBodHRwOi8vd3d3LmVhc3lzb2Z0LmNvbS9kZXZlbG9w
ZXIvbGFuZ3VhZ2VzL2Mvb2RiY190dXRvcmlhbC5odG1sDQogKi8NCnZvaWQg
cHJpbnRfZXJyb3IoY2hhciAqbG9jYXRpb24sU1FMSEFORExFIGhhbmRsZSxT
UUxTTUFMTElOVCB0eXBlKQ0Kew0KICAgIFNRTElOVEVHRVIJIGkgPSAwOw0K
ICAgIFNRTElOVEVHRVIJIG5hdGl2ZTsNCiAgICBTUUxDSEFSCSBzdGF0ZVsg
NyBdOw0KICAgIFNRTENIQVIJIHRleHRbMjU2XTsNCiAgICBTUUxTTUFMTElO
VAkgbGVuOw0KICAgIFNRTFJFVFVSTgkgcmV0Ow0KDQogICAgcHJpbnRmKCJF
cnJvciBlbmNvdW50ZXJlZCBpbiAlc1xuIERpYWdub3N0aWNzIGZvbGxvdzot
XG4iLGxvY2F0aW9uKTsNCg0KICAgIGRvew0KICAgICAgICByZXQgPSBTUUxH
ZXREaWFnUmVjKHR5cGUsIGhhbmRsZSwgKytpLCBzdGF0ZSwgJm5hdGl2ZSwg
dGV4dCwNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICBzaXplb2YodGV4
dCksICZsZW4gKTsNCiAgICAgICAgaWYgKFNRTF9TVUNDRUVERUQocmV0KSkN
CiAgICAgICAgICAgIHByaW50ZigiJXM6JWxkOiVsZDolc1xuIiwgc3RhdGUs
IGksIG5hdGl2ZSwgdGV4dCk7DQogICAgfXdoaWxlKHJldCA9PSBTUUxfU1VD
Q0VTUyk7DQp9DQoNClNRTENIQVIgKmdldF9jb2x1bW5fbmFtZShTUUxIU1RN
VCBzdG10LGNoYXIgKmJ1Zil7DQoNCiAgICBTUUxJTlRFR0VSIG5hbWVfY29s
PTQ7DQogICAgU1FMTEVOIGluZDsNCg0KICAgIFNRTEdldERhdGEoc3RtdCxu
YW1lX2NvbCxTUUxfQ19DSEFSLGJ1ZixzaXplb2YoYnVmKSwmaW5kKTsNCiAg
ICByZXR1cm4gYnVmOw0KfQ0KDQppbnQgc2hvd19jb2x1bW5zKFNRTEhTVE1U
IHN0bXQsdW5zaWduZWQgY2hhciAqc2NoZW1hLHVuc2lnbmVkIGNoYXIgKnRh
YmxlKXsNCg0KICAgIFNRTFJFVFVSTiByZXQ7DQogICAgU1FMU01BTExJTlQg
cmVzOw0KICAgIGNoYXIgYnVmWzI1NV07DQogICAgaW50IGk9MDsNCg0KICAg
IC8qIERvIGEgU1FMQ29sdW1ucyBvbiB0aGUgdGFibGUgKi8NCiAgICBpZigh
U1FMX1NVQ0NFRURFRChyZXQ9U1FMQ29sdW1ucyhzdG10LA0KCQkJCSAgICAg
IE5VTEwsMCwNCgkJCQkgICAgICBzY2hlbWEsc2NoZW1hP1NRTF9OVFM6MCwN
CgkJCQkgICAgICB0YWJsZSxTUUxfTlRTLA0KCQkJCSAgICAgICh1bnNpZ25l
ZCBjaGFyICopIiUiLCBTUUxfTlRTKSkpew0KCSAgICAgcHJpbnRfZXJyb3Io
IlNRTENvbHVtbnMiLHN0bXQsU1FMX0hBTkRMRV9TVE1UKTsNCgkgICAgIHJl
dHVybiByZXQ7DQogICAgfQ0KDQogICAgLyogTG9vcCB0aHJvdWdoIHJlc3Vs
dHMgdG8gZW51bWVyYXRlIHRoZSBjb2x1bW5zICovDQogICAgd2hpbGUoKHJl
dD1TUUxGZXRjaChzdG10KSkgIT0gU1FMX05PX0RBVEEgJiYgcmV0IT1TUUxf
RVJST1Ipew0KCXByaW50ZigiQ29sdW1uICVpOiAlc1xuIixpKyssZ2V0X2Nv
bHVtbl9uYW1lKHN0bXQsYnVmKSk7DQogICAgfQ0KDQogICAgLyogV2h5IHdl
cmUgbm8gY29sdW1ucyBkZXNjcmliZWQ/ICovDQogICAgaWYoaT09MCl7DQoJ
c3dpdGNoKHJldCl7DQoJICBjYXNlIFNRTF9OT19EQVRBOnByaW50ZigiTm8g
ZGF0YSFcbiIpOw0KCSAgICBicmVhazsNCgkgIGNhc2UgU1FMX0VSUk9SOnBy
aW50ZigiRXJyb3IhXG4iKTsNCgkgICAgYnJlYWs7DQoJICBkZWZhdWx0Og0K
CSAgICBwcmludGYoIk90aGVyPSVpXG4iLHJldCk7DQoJfQ0KICAgIH0NCiAg
ICByZXR1cm4gcmV0Ow0KfQ0KDQppbnQgZGVzY3JpYmVfdGFibGUoU1FMSERC
QyBjb24sU1FMQ0hBUiAqc2NoZW1hLFNRTENIQVIgKnRhYmxlKXsNCg0KICAg
IFNRTFJFVFVSTiByZXQ7DQogICAgU1FMSFNUTVQgc3RtdDsNCg0KICAgIHBy
aW50ZigiXG5HZXR0aW5nIGNvbHVtbnMgZnJvbSAlcy4lc1xuIixzY2hlbWEs
dGFibGUpOw0KICAgIGlmKCFTUUxfU1VDQ0VFREVEKHJldD1TUUxBbGxvY0hh
bmRsZShTUUxfSEFORExFX1NUTVQsY29uLCZzdG10KSkpew0KCXByaW50X2Vy
cm9yKCJzdG10IGhhbmRsZSIsc3RtdCxTUUxfSEFORExFX1NUTVQpOw0KCXJl
dHVybiByZXQ7DQogICAgfQ0KICAgIHJldD1zaG93X2NvbHVtbnMoc3RtdCxz
Y2hlbWEsdGFibGUpOw0KICAgIFNRTEZyZWVIYW5kbGUoU1FMX0hBTkRMRV9T
VE1ULCBzdG10KTsNCiAgICByZXR1cm4gcmV0Ow0KfQ0KDQpTUUxDSEFSICpu
ZXdfcm93X3NlbGVjdChTUUxDSEFSICpzY2hlbWEsU1FMQ0hBUiAqdGFibGUp
ew0KDQogICAgU1FMQ0hBUiAqc2VsZWN0PShTUUxDSEFSICopbWFsbG9jKHNp
emVvZihTUUxDSEFSKSoyNTUpOw0KDQogICAgaWYoc2NoZW1hKXsNCglzcHJp
bnRmKHNlbGVjdCwic2VsZWN0ICogZnJvbSAlcy4lcyIsc2NoZW1hLHRhYmxl
KTsNCiAgICB9ZWxzZXsNCglzcHJpbnRmKHNlbGVjdCwic2VsZWN0ICogZnJv
bSAlcyIsdGFibGUpOw0KICAgIH0NCg0KICAgIHJldHVybiBzZWxlY3Q7DQp9
DQoNCmludCBzaG93X2RhdGEoU1FMSFNUTVQgc3RtdCl7DQoNCiAgICBTUUxS
RVRVUk4gcmV0Ow0KICAgIFNRTFNNQUxMSU5UIGNvbDsNCiAgICBpbnQgaT0w
LGo7DQoNCiAgICAvKiBIb3cgbWFueSBjb2x1bW5zIGFyZSB0aGVyZT8gKi8N
CiAgICBpZighU1FMX1NVQ0NFRURFRChTUUxOdW1SZXN1bHRDb2xzKHN0bXQs
JmNvbCkpKXsNCglwcmludF9lcnJvcigiZ2V0IG51bSBjb2x1bW5zIixzdG10
LFNRTF9IQU5ETEVfU1RNVCk7DQoJcmV0dXJuIDA7DQogICAgfQ0KDQogICAg
LyogTG9vcCB0aHJvdWdoIHJlc3VsdHMgdG8gZGlzcGxheSB0aGUgZGF0YSAq
Lw0KICAgIHdoaWxlKChyZXQ9U1FMRmV0Y2goc3RtdCkpICE9IFNRTF9OT19E
QVRBICYmIHJldCE9U1FMX0VSUk9SKXsNCglwcmludGYoIlJvdyAlaToiLGkr
Kyk7DQoJZm9yKGo9MTtqPD1jb2w7aisrKXsNCgkgICAgU1FMTEVOIGluZDsN
CgkgICAgY2hhciBidWZbMjU1XTsNCgkgICAgaWYoU1FMX1NVQ0NFRURFRCgN
CgkJICAgU1FMR2V0RGF0YShzdG10LGosU1FMX0NfQ0hBUixidWYsc2l6ZW9m
KGJ1ZiksJmluZCkpKXsNCgkJaWYoaW5kPT1TUUxfTlVMTF9EQVRBKQ0KCQkg
ICAgcHJpbnRmKCIlaT1OVUxMOyIsaik7DQoJCWVsc2UNCgkJICAgIHByaW50
ZigiJWk9JXM7IixqLGJ1Zik7DQoJICAgIH0NCgl9DQoJcHJpbnRmKCJcbiIp
Ow0KICAgIH0NCg0KICAgIHJldHVybiBpOw0KfQ0KDQppbnQgc2VsZWN0X3Rh
YmxlKFNRTEhEQkMgY29uLFNRTENIQVIgKnNjaGVtYSxTUUxDSEFSICp0YWJs
ZSl7DQoNCiAgICBTUUxSRVRVUk4gcmV0Ow0KICAgIFNRTEhTVE1UIHN0bXQ7
DQogICAgU1FMQ0hBUiAqc2VsZWN0Ow0KDQogICAgcHJpbnRmKCJcbkdldHRp
bmcgYWxsIHJvd3MgZnJvbSAlcy4lc1xuIixzY2hlbWEsdGFibGUpOw0KICAg
IGlmKCFTUUxfU1VDQ0VFREVEKHJldD1TUUxBbGxvY0hhbmRsZShTUUxfSEFO
RExFX1NUTVQsY29uLCZzdG10KSkpew0KCXByaW50X2Vycm9yKCJzdG10IGhh
bmRsZSIsc3RtdCxTUUxfSEFORExFX1NUTVQpOw0KCXJldHVybiByZXQ7DQog
ICAgfQ0KDQogICAgc2VsZWN0PW5ld19yb3dfc2VsZWN0KHNjaGVtYSx0YWJs
ZSk7DQogICAgaWYoIVNRTF9TVUNDRUVERUQocmV0PVNRTEV4ZWNEaXJlY3Qo
c3RtdCxzZWxlY3QsU1FMX05UUykpKXsNCglwcmludF9lcnJvcigic3RtdCBz
ZWxlY3QiLHN0bXQsU1FMX0hBTkRMRV9TVE1UKTsNCglyZXR1cm4gcmV0Ow0K
ICAgIH0NCg0KICAgIHNob3dfZGF0YShzdG10KTsNCg0KICAgIFNRTEZyZWVI
YW5kbGUoU1FMX0hBTkRMRV9TVE1ULCBzdG10KTsNCiAgICBmcmVlKHNlbGVj
dCk7DQogICAgcmV0dXJuIHJldDsNCn0NCg0KaW50IG1haW4oaW50IGFyZ2Ms
IGNoYXIgKiphcmd2KXsNCg0KICAgIFNRTEhFTlYgZW52Ow0KICAgIFNRTEhE
QkMgZGJjOw0KICAgIFNRTFJFVFVSTiByZXQ7DQoNCiAgICBTUUxDSEFSICpk
c249InBieCI7DQogICAgU1FMQ0hBUiAqc2NoZW1hPSJ0ZXN0X3NjaGVtYSI7
DQogICAgU1FMQ0hBUiAqcHVibGljPSJwdWJsaWMiOw0KICAgIFNRTENIQVIg
KnRhYmxlPSJ0ZXN0IjsNCg0KICAgIHByaW50ZigiU1FMQ29sdW1ucyBDb25u
ZWN0aW9uIFRlc3RcbiIpOw0KICAgIA0KICAgIC8qIENyZWF0ZSBjb25uZWN0
aW9uIGhhbmRsZXMgKi8NCiAgICBpZighU1FMX1NVQ0NFRURFRChyZXQ9U1FM
QWxsb2NIYW5kbGUoDQoJCQkgIFNRTF9IQU5ETEVfRU5WLCBTUUxfTlVMTF9I
QU5ETEUsICZlbnYpKSl7DQoJcHJpbnRfZXJyb3IoImVudiBoYW5kbGUiLGRi
YyxTUUxfSEFORExFX0VOVik7DQogICAgfQ0KICAgIGlmKCFTUUxfU1VDQ0VF
REVEKHJldD1TUUxTZXRFbnZBdHRyKA0KCQkJICBlbnYsU1FMX0FUVFJfT0RC
Q19WRVJTSU9OLCh2b2lkICopU1FMX09WX09EQkMyLCAwKSkpew0KIAlwcmlu
dF9lcnJvcigib2RiYyB2ZXJzaW9uIixkYmMsU1FMX0hBTkRMRV9FTlYpOw0K
ICAgIH0NCiAgICBpZighU1FMX1NVQ0NFRURFRChyZXQ9U1FMQWxsb2NIYW5k
bGUoU1FMX0hBTkRMRV9EQkMsIGVudiwgJmRiYykpKXsNCglwcmludF9lcnJv
cigiY29ubmVjdGlvbiBoYW5kbGUiLGRiYyxTUUxfSEFORExFX0RCQyk7DQog
ICAgfQ0KDQogICAgcHJpbnRmKCJIYW5kbGVzIEFsbG9jYXRlZFxuIik7DQoN
CiAgICAvKiBDb25uZWN0IHRvIHRoZSBkYXRhYmFzZSAqLw0KICAgIGlmKCFT
UUxfU1VDQ0VFREVEKHJldD1TUUxDb25uZWN0KGRiYyxkc24sU1FMX05UUyxO
VUxMLDAsTlVMTCwwKSkpew0KCXByaW50X2Vycm9yKCJjb25uZWN0aW9uIixk
YmMsU1FMX0hBTkRMRV9EQkMpOw0KICAgIH0NCg0KICAgIC8qIEluIHR1cm4s
IGRlc2NyaWJlIGVhY2ggdGFibGUgYW5kIGdldCB0aGUgY29udGVudHMgKi8N
CiAgICBkZXNjcmliZV90YWJsZShkYmMsc2NoZW1hLHRhYmxlKTsNCiAgICBz
ZWxlY3RfdGFibGUoZGJjLHNjaGVtYSx0YWJsZSk7DQoNCiAgICBkZXNjcmli
ZV90YWJsZShkYmMscHVibGljLHRhYmxlKTsNCiAgICBzZWxlY3RfdGFibGUo
ZGJjLHB1YmxpYyx0YWJsZSk7DQoNCiAgICBkZXNjcmliZV90YWJsZShkYmMs
TlVMTCx0YWJsZSk7DQogICAgc2VsZWN0X3RhYmxlKGRiYyxOVUxMLHRhYmxl
KTsNCg0KDQogICAgLyogRnJlZSBoYW5kbGVzICovDQogICAgU1FMRnJlZUhh
bmRsZShTUUxfSEFORExFX0RCQywgZGJjKTsNCiAgICBTUUxGcmVlSGFuZGxl
KFNRTF9IQU5ETEVfRU5WLCBlbnYpOw0KfQ0K

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


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

--_002_806CB309AA19EE4F8F30EB5DF3E372B33B5E635C4DEMV61UKRDdo ma_--

Report this message

#5: Re: Issues when using schema names with odbc

Posted on 2010-11-30 15:17:30 by Hiroshi Inoue

(2010/11/29 23:51), michael.28.smith@bt.com wrote:
> Used a little test app to verify this and I get different results,
>
> Assuming create schema test_schema;
>
> create table public.test(
> row1 int,
> row2 text);
>
> create table test_schema.test(
> row_t_1 int,
> row_t_2 text);
>
> grant usage on schema test_schema to public;
> grant select on public.test to public;
> grant select on test_schema.test to public;
>
> insert into public.test values (1,'public schema');
> insert into test_schema.test values (2,'test schema');
>
> The test app shows the following results....:
>
> [root@winston scripts]# ./sqltest
> SQLColumns Connection Test
> Handles Allocated
>
> Getting columns from test_schema.test
> No data!
>
> Getting all rows from test_schema.test
> Row 0:1=3D2;2=3Dtest schema;
>
> Getting columns from public.test
> No data!
>
> Getting all rows from public.test
> Row 0:1=3D1;2=3Dpublic schema;
>
> Getting columns from (null).test
> Column 0: row
> Column 1: row
> Column 2: row
> Column 3: row
>
> Getting all rows from (null).test
> Row 0:1=3D1;2=3Dpublic schema;

Which version of psqlodbcã€=80driver are you using?
Here I get the following results.

Getting columns from test_schema.test
Column 0: row_t_1
Column 1: row_t_2

Getting all rows from test_schema.test
Row 0:1=3D2;2=3Dtest schema;

Getting columns from public.test
Column 0: row1
Column 1: row2

Getting all rows from public.test
Row 0:1=3D1;2=3Dpublic schema;

Getting columns from (null).test
Column 0: row1
Column 1: row2

Getting all rows from (null).test
Row 0:1=3D1;2=3Dpublic schema;

regards,
Hiroshi Inoue


--=20
Sent via pgsql-odbc mailing list (pgsql-odbc@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-odbc

Report this message

#6: Re: Issues when using schema names with odbc

Posted on 2010-11-30 15:38:44 by michael.28.smith

W2J0b2NAcmRsMTAwOTBhcHAxNSB+XSQgcnBtIC1xYSB8Z3JlcCBvZGJjDQpw
b3N0Z3Jlc3FsLW9kYmMtMDguMDEuMDIwMC0zLjENCg0KQXJlIHlvdSB1c2lu
ZyBhIGxhdGVyIHZlcnNpb24gPyBpcyBzbyB3aGljaCBvbmUgYW5kIGFueSBp
ZGVhcyB3aGF0IHZlcnNpb24gaXQgaGFzIGJlZW4gZml4ZWQgaW4gPw0KDQpD
aGVlcnMNCg0KDQpNaWtlIFNtaXRoDQpWb2ljZSAmIE11bHRpbWVkaWEgUGxh
dGZvcm0gfCBCVCBJbm5vdmF0ZSAmIERlc2lnbg0KVGVsOiArNDQgKDApIDIw
wqA3ODc2wqA4MDA1DQpDbGlja0RpYWwgTWUNCg0KLS0tLS1PcmlnaW5hbCBN
ZXNzYWdlLS0tLS0NCkZyb206IEhpcm9zaGkgSW5vdWUgW21haWx0bzppbm91
ZUB0cGYuY28uanBdIA0KU2VudDogMzAgTm92ZW1iZXIgMjAxMCAxNDoxNw0K
VG86IFNtaXRoLE0sTWljaGFlbCxETFcgQw0KQ2M6IHBnc3FsLW9kYmNAcG9z
dGdyZXNxbC5vcmc7IEhpbmRtYXJjaCxTSixTdGVwaGVuLERMVyBSDQpTdWJq
ZWN0OiBSZTogW09EQkNdIElzc3VlcyB3aGVuIHVzaW5nIHNjaGVtYSBuYW1l
cyB3aXRoIG9kYmMNCg0KKDIwMTAvMTEvMjkgMjM6NTEpLCBtaWNoYWVsLjI4
LnNtaXRoQGJ0LmNvbSB3cm90ZToNCj4gVXNlZCBhIGxpdHRsZSB0ZXN0IGFw
cCB0byB2ZXJpZnkgdGhpcyBhbmQgSSBnZXQgZGlmZmVyZW50IHJlc3VsdHMs
DQo+DQo+IEFzc3VtaW5nIGNyZWF0ZSBzY2hlbWEgdGVzdF9zY2hlbWE7DQo+
DQo+IGNyZWF0ZSB0YWJsZSBwdWJsaWMudGVzdCgNCj4gCXJvdzEgaW50LA0K
PiAJcm93MiB0ZXh0KTsNCj4NCj4gY3JlYXRlIHRhYmxlIHRlc3Rfc2NoZW1h
LnRlc3QoDQo+IAlyb3dfdF8xIGludCwNCj4gCXJvd190XzIgdGV4dCk7DQo+
DQo+IGdyYW50IHVzYWdlIG9uIHNjaGVtYSB0ZXN0X3NjaGVtYSB0byBwdWJs
aWM7DQo+IGdyYW50IHNlbGVjdCBvbiBwdWJsaWMudGVzdCB0byBwdWJsaWM7
DQo+IGdyYW50IHNlbGVjdCBvbiB0ZXN0X3NjaGVtYS50ZXN0IHRvIHB1Ymxp
YzsNCj4NCj4gaW5zZXJ0IGludG8gcHVibGljLnRlc3QgdmFsdWVzICgxLCdw
dWJsaWMgc2NoZW1hJyk7DQo+IGluc2VydCBpbnRvIHRlc3Rfc2NoZW1hLnRl
c3QgdmFsdWVzICgyLCd0ZXN0IHNjaGVtYScpOw0KPg0KPiBUaGUgdGVzdCBh
cHAgc2hvd3MgdGhlIGZvbGxvd2luZyByZXN1bHRzLi4uLjoNCj4NCj4gW3Jv
b3RAd2luc3RvbiBzY3JpcHRzXSMgLi9zcWx0ZXN0DQo+IFNRTENvbHVtbnMg
Q29ubmVjdGlvbiBUZXN0DQo+IEhhbmRsZXMgQWxsb2NhdGVkDQo+DQo+IEdl
dHRpbmcgY29sdW1ucyBmcm9tIHRlc3Rfc2NoZW1hLnRlc3QNCj4gTm8gZGF0
YSENCj4NCj4gR2V0dGluZyBhbGwgcm93cyBmcm9tIHRlc3Rfc2NoZW1hLnRl
c3QNCj4gUm93IDA6MT0yOzI9dGVzdCBzY2hlbWE7DQo+DQo+IEdldHRpbmcg
Y29sdW1ucyBmcm9tIHB1YmxpYy50ZXN0DQo+IE5vIGRhdGEhDQo+DQo+IEdl
dHRpbmcgYWxsIHJvd3MgZnJvbSBwdWJsaWMudGVzdA0KPiBSb3cgMDoxPTE7
Mj1wdWJsaWMgc2NoZW1hOw0KPg0KPiBHZXR0aW5nIGNvbHVtbnMgZnJvbSAo
bnVsbCkudGVzdA0KPiBDb2x1bW4gMDogcm93DQo+IENvbHVtbiAxOiByb3cN
Cj4gQ29sdW1uIDI6IHJvdw0KPiBDb2x1bW4gMzogcm93DQo+DQo+IEdldHRp
bmcgYWxsIHJvd3MgZnJvbSAobnVsbCkudGVzdA0KPiBSb3cgMDoxPTE7Mj1w
dWJsaWMgc2NoZW1hOw0KDQpXaGljaCB2ZXJzaW9uIG9mIHBzcWxvZGJj44CA
ZHJpdmVyIGFyZSB5b3UgdXNpbmc/DQpIZXJlIEkgZ2V0IHRoZSBmb2xsb3dp
bmcgcmVzdWx0cy4NCg0KR2V0dGluZyBjb2x1bW5zIGZyb20gdGVzdF9zY2hl
bWEudGVzdA0KQ29sdW1uIDA6IHJvd190XzENCkNvbHVtbiAxOiByb3dfdF8y
DQoNCkdldHRpbmcgYWxsIHJvd3MgZnJvbSB0ZXN0X3NjaGVtYS50ZXN0DQpS
b3cgMDoxPTI7Mj10ZXN0IHNjaGVtYTsNCg0KR2V0dGluZyBjb2x1bW5zIGZy
b20gcHVibGljLnRlc3QNCkNvbHVtbiAwOiByb3cxDQpDb2x1bW4gMTogcm93
Mg0KDQpHZXR0aW5nIGFsbCByb3dzIGZyb20gcHVibGljLnRlc3QNClJvdyAw
OjE9MTsyPXB1YmxpYyBzY2hlbWE7DQoNCkdldHRpbmcgY29sdW1ucyBmcm9t
IChudWxsKS50ZXN0DQpDb2x1bW4gMDogcm93MQ0KQ29sdW1uIDE6IHJvdzIN
Cg0KR2V0dGluZyBhbGwgcm93cyBmcm9tIChudWxsKS50ZXN0DQpSb3cgMDox
PTE7Mj1wdWJsaWMgc2NoZW1hOw0KDQpyZWdhcmRzLA0KSGlyb3NoaSBJbm91
ZQ0KDQoKLS0gClNlbnQgdmlhIHBnc3FsLW9kYmMgbWFpbGluZyBsaXN0IChw
Z3NxbC1vZGJjQHBvc3RncmVzcWwub3JnKQpUbyBtYWtlIGNoYW5nZXMgdG8g
eW91ciBzdWJzY3JpcHRpb246Cmh0dHA6Ly93d3cucG9zdGdyZXNxbC5vcmcv
bWFpbHByZWYvcGdzcWwtb2RiYwo=

Report this message