Issues when using schema names with odbc
Issues when using schema names with odbc
am 18.11.2010 17:22:30 von 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
--_000_806CB309AA19EE4F8F30EB5DF3E372B33B41580830EMV61UKRDdo ma_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
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">
I think there is an issue with the following version o=
f
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.
This assumes the identical tables are in public.table_=
name
and schema.table_name
I actually come across this when using asterisk realti=
me
– I was about to raise this as an asterisk issue and came across this
– which suggests it is actually an underlying odbc issue.<=
/p>
5963">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<=
/o:p>
postgresql-8.1.11-1.el5_1.1=
postgresql-libs-8.1.11-1.el5_1.1<=
/o:p>
postgresql-odbc-08.01.0200-3.1
:p>
Asterisk 1.6.2.12,
color:black'>Mike Smith
color:black'>Voice & Multimedia Platform | BT Innovate & Design
an>
style=3D'color:blue'>
color:black'>Tel: +44 (0)
:"Arial","sans-serif"'>20 7876 8005
ns-serif"'>
href=3D"http://www.ibridge.bt.com/ClickDial/MakeCall?+442078 768005">ClickDi=
al Me
--_000_806CB309AA19EE4F8F30EB5DF3E372B33B41580830EMV61UKRDdo ma_--
Re: Issues when using schema names with odbc
am 20.11.2010 03:33:01 von 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
Re: Issues when using schema names with odbc
am 29.11.2010 15:51:00 von 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
Re: Issues when using schema names with odbc
am 29.11.2010 16:03:19 von 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_--
Re: Issues when using schema names with odbc
am 30.11.2010 15:17:30 von 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
Re: Issues when using schema names with odbc
am 30.11.2010 15:38:44 von 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=