pg.ddx.io pgsql-interfaces@postgresql.org mailing list archive
help / color / mirror / Atom feedpsqlodbc
16+ messages / 6 participants
[nested] [flat]
* psqlodbc
@ 1998-07-28 02:22 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-28 06:45 ` Re: [INTERFACES] psqlodbc Aleksey Demakov <avd@gcom.ru>
0 siblings, 1 reply; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-07-28 02:22 UTC (permalink / raw)
To: pgsql-interfaces
I'm trying to build the ODBC driver to use with an iODBC interface for
the upcoming release of ApplixWare on Linux. I notice that in the last
few days the psqlodbc distribution has acquired a Makefile and a
README.Linux, but the build is not going very well.
Has anyone tried to build on a Unix box recently? If so, how?? The first
file fails on a WINAPI-ed typedef...
- Tom
golem$ make
gcc -g -c -Wall -O -fPIC -I. -I.. -I -I -g -DHAVE_CONFIG_H -c
info.c -o info.o
In file included from info.c:41:
connection.h:166: parse error before `*'
connection.h:177: parse error before `*'
connection.h:202: parse error before `HINSTANCE'
connection.h:202: warning: no semicolon at end of struct or union
connection.h:203: warning: data definition has no type or storage class
connection.h:204: parse error before `DriverToDataSource'
connection.h:204: warning: data definition has no type or storage class
connection.h:207: parse error before `}'
info.c: In function `SQLGetInfo':
info.c:190: dereferencing pointer to incomplete type
info.c:197: dereferencing pointer to incomplete type
info.c:302: dereferencing pointer to incomplete type
info.c:303: dereferencing pointer to incomplete type
info.c:622: dereferencing pointer to incomplete type
info.c:717: dereferencing pointer to incomplete type
info.c:724: dereferencing pointer to incomplete type
info.c:725: dereferencing pointer to incomplete type
info.c:62: warning: `p' might be used uninitialized in this function
info.c: In function `SQLGetTypeInfo':
info.c:746: warning: left-hand operand of comma expression has no effect
info.c:746: warning: statement with no effect
info.c: In function `SQLTables':
info.c:1007: warning: left-hand operand of comma expression has no
effect
info.c:1007: warning: statement with no effect
info.c:1017: dereferencing pointer to incomplete type
info.c:1180: warning: left-hand operand of comma expression has no
effect
info.c:1180: warning: left-hand operand of comma expression has no
effect
info.c:1180: warning: left-hand operand of comma expression has no
effect
info.c:1180: warning: statement with no effect
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-28 02:22 psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-07-28 06:45 ` Aleksey Demakov <avd@gcom.ru>
1998-07-30 05:10 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 16+ messages in thread
From: Aleksey Demakov @ 1998-07-28 06:45 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; byronn@insightdist.com; pgsql-interfaces
"Thomas G. Lockhart" <lockhart@alumni.caltech.edu> writes:
>
> I'm trying to build the ODBC driver to use with an iODBC interface for
> the upcoming release of ApplixWare on Linux. I notice that in the last
> few days the psqlodbc distribution has acquired a Makefile and a
> README.Linux, but the build is not going very well.
>
> Has anyone tried to build on a Unix box recently? If so, how?? The first
> file fails on a WINAPI-ed typedef...
>
Try with this patch. Since I doubt anyone needs translation DLLs under
linux I simply ifdefed out some code. Though it's posible to use
dlopen/dlsym/dlclose instead of LoadLibrary/GetProcAddress/FreeLibrary...
Aleksey
inline patch 1: psqlodbc/connection.c, psqlodbc/connection.h (+12/-2 lines) download inline-1.patch
diff -c psqlodbc.old/connection.c psqlodbc/connection.c
*** psqlodbc.old/connection.c Tue Jul 28 13:03:23 1998
--- psqlodbc/connection.c Tue Jul 28 12:57:17 1998
***************
*** 380,390 ****
--- 380,392 ----
}
}
+ #ifndef UNIX
/* Check for translation dll */
if ( self->translation_handle) {
FreeLibrary (self->translation_handle);
self->translation_handle = NULL;
}
+ #endif
mylog("exit CC_Cleanup\n");
return TRUE;
***************
*** 393,399 ****
int
CC_set_translation (ConnectionClass *self)
{
!
if (self->translation_handle != NULL) {
FreeLibrary (self->translation_handle);
self->translation_handle = NULL;
--- 395,401 ----
int
CC_set_translation (ConnectionClass *self)
{
! #ifndef UNIX
if (self->translation_handle != NULL) {
FreeLibrary (self->translation_handle);
self->translation_handle = NULL;
***************
*** 424,429 ****
--- 426,432 ----
self->errormsg = "Could not find translation DLL functions.";
return FALSE;
}
+ #endif
return TRUE;
}
diff -c psqlodbc.old/connection.h psqlodbc/connection.h
*** psqlodbc.old/connection.h Tue Jul 28 13:03:10 1998
--- psqlodbc/connection.h Tue Jul 28 12:36:56 1998
***************
*** 162,167 ****
--- 162,174 ----
char name[MAX_TABLE_LEN+1];
};
+ #ifdef UNIX
+ #define WINAPI CALLBACK
+ #define DLLHANDLE void *
+ #else
+ #define DLLHANDLE HINSTANCE
+ #endif
+
/* Translation DLL entry points */
typedef BOOL (FAR WINAPI *DataSourceToDriverProc) (UDWORD,
SWORD,
***************
*** 199,205 ****
int ntables;
COL_INFO **col_info;
long translation_option;
! HINSTANCE translation_handle;
DataSourceToDriverProc DataSourceToDriver;
DriverToDataSourceProc DriverToDataSource;
char transact_status; /* Is a transaction is currently in progress */
--- 206,212 ----
int ntables;
COL_INFO **col_info;
long translation_option;
! DLLHANDLE translation_handle;
DataSourceToDriverProc DataSourceToDriver;
DriverToDataSourceProc DriverToDataSource;
char transact_status; /* Is a transaction is currently in progress */
* Re: [INTERFACES] psqlodbc
1998-07-28 02:22 psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-28 06:45 ` Re: [INTERFACES] psqlodbc Aleksey Demakov <avd@gcom.ru>
@ 1998-07-30 05:10 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-31 02:44 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-07-30 05:10 UTC (permalink / raw)
To: Aleksey Demakov <avd@gcom.ru>; mr.linux@applix.com; +Cc: byronn@insightdist.com; pgsql-interfaces
> > I'm trying to build the ODBC driver to use with an iODBC interface
> > for the upcoming release of ApplixWare on Linux.
> Try with this patch.
OK, that seems to help (though there is still major ugliness with the
macro which disables mylog()).
Anyway, I now have a sharable library, and ApplixWare is running. But I
don't see any candidate servers when I try to select a database to open.
I made a ~/.odbc.ini file, and included entries like:
[Postgres]
Debug = 0
CommLog = 1
Driver = /opt/postgres/current/lib/libpsqlodbc.so
but see nothing in the ApplixWare dialog box. Does anyone have a working
.odbc.ini file, perhaps for MySQL? I guess I expected to see "Postgres"
as a candidate database in the ApplixWare dialog box, even if the rest
of the configuration was screwed up. What else needs to be set up??
TIA
- Tom
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-28 02:22 psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-28 06:45 ` Re: [INTERFACES] psqlodbc Aleksey Demakov <avd@gcom.ru>
1998-07-30 05:10 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-07-31 02:44 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-07-31 02:44 UTC (permalink / raw)
To: Aleksey Demakov <avd@gcom.ru>; MrLinux@applix.com, Gerald Gryschuk <ggryschuk@scf.sk.ca>; +Cc: Postgres Hackers List <hackers@postgresql.org>
> > Anyway, I now have a sharable library, and ApplixWare is running.
> > But I don't see any candidate servers...
> > I made a ~/.odbc.ini file...
> you need one other entry which corresponds to the Postgres entry...
> You'll then see a "Postgres Database" entry in the appropriate Data
> dialog box.
OK, I followed this suggestion from the Applix folks and it helped. Here
is the file which does better:
<start .odbc.ini file>
[ODBC Data Sources]
Postgres = Postgres Data
[Postgres]
Debug = 0
CommLog = 1
Driver = /opt/postgres/current/lib/libpsqlodbc.so
<eof>
An now Applix can see some candidates. I then got an error from Applix
regarding a missing library:
/opt/applix/axdata/elfodbc: can't load library 'libodbc.so'
which was apparently in the wrong directory in the Applix distribution.
So, I made a soft link to the normal directory area, and now Applix got
further, asking me for a username and password. However, I got the
following error after that:
/opt/applix/axdata/elfodbc: can't resolve symbol 'parse_statement'
When I run "nm" on /opt/postgres/current/lib/libpsqlodbc.so.0.24 I see
the following entry:
mythos> nm libpsqlodbc.so.0.24 | grep -i parse_statement
U parse_statement
which indicates an unresolved symbol. So, I found that parse.c was not
being compiled by Makefile.unx (and my derivative) so got that compiled
and linked and things are much closer to working! :)
OK, so now I get an error message saying:
missing a username, port, or server name
if I use an entry in .odbc.ini which only specifies the driver library
(as above), and I get a similar error message when I specify an
.odbc.ini entry which looks like:
[PostgresFull]
DSN = test
Server = localhost
UID = tgl
Port = 5432
Driver = /opt/postgres/current/lib/libpsqlodbc.so
If I explicitly type the server name (as "localhost") in the Applix
dialog box, I get a different error message:
axnet: Cannot launch gateway on server
not a tcp service in /etc/services
So, anyone have any other hints? What information must be in a real
.odbc.ini file for MySQL to work? I don't have much security turned on
in Postgres, but do have the TCP/IP option specified on the server.
Tried adding an entry in /etc/services, but that alone didn't change the
error message. Anyone have more hints?? :)
- Tom
Oh, btw I have started fixing up a makefile which actually fits into the
Postgres distribution...
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
@ 1998-07-31 15:27 Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-07-31 15:27 UTC (permalink / raw)
To: MrLinux@applix.com, Aleksey Demakov <avd@gcom.ru>; +Cc: pgsql-interfaces
> I've included the HOWTO I recently wrote for mySQL that will be
> distributed with the upcoming 4.4.1 release; hope this helps.
That helped a lot Eric. Thanks.
So, here is the current status:
1) the psqlodbc driver has the database information section _hardcoded_
as "PostgreSQL".
2) the psqlodbc driver does not successfully read the .odbc.ini file (or
at least doesn't read any of the entries I've put into it). That
explains why the log files were not being written and why things like
the server name and port number were never being set.
3) I guess it shouldn't suprise me, but the psqlodbc driver does not use
libpq to interface with Postgres. Byron and company have done a lot of
work recreating it.
Off to work now. Will try some more this evening...
- Tom
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-08-01 17:08 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 19:48 ` Re: [INTERFACES] psqlodbc David Hartwig <daybee@bellatlantic.net>
1998-08-02 14:51 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 2 replies; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-08-01 17:08 UTC (permalink / raw)
To: MrLinux@applix.com, Aleksey Demakov <avd@gcom.ru>; David Hartwig <daybee@bellatlantic.net>; Byron Nikolaidis <byronn@insightdist.com>; +Cc: pgsql-interfaces
OK, I've gotten a ways farther; here is the current status on the
ApplixWare->Postgres interface via iODBC using the Insight driver:
1) The psqlodbc driver does not use a hardcoded database name as I had
reported earlier; there is some fallback code which does but that is not
getting executed.
2) ApplixWare/iodbc is handing the psqlodbc driver a registry "section"
name string which has a trailing blank. So, the driver was never finding
a match in the .odbc.ini file for that block because it wasn't stripping
blanks from the target strings (it does strip blanks correctly from the
.ini file entries themselves). I brute-force fixed that by stripping the
blanks in the psqlodbc .ini reader (in gpps.c), but we should fix it
when the driver gets the string from the app. Any idea where that is?
3) The driver appears to successfully complete a few of the transactions
involved in starting up the database connection, including one or two
queries. It returns from SQLConnect() with a SQL_SUCCESS return code.
4) After that point Applix reports a "broken pipe". Log info from the
"psqlodbc" and "mylog" debugging files is at the end of the mail. It
looks like SQLConnect() is returning, but I don't know what should
happen next to see where things are bombing out.
So, questions:
Does anyone have a suggestion on which driver routines get called by
Applix/iodbc and in what order? Is there any debugging I can turn on in
Applix or in the iodbc driver? Any ideas on where to look next?
- Tom
golem> cat psqlodbc.log
DSN info:
DSN='PostgreSQL',server='localhost',port='5432',dbase='test',user='tgl',passwd=''
readonly='',protocol='',showoid='',fakeoidindex='',showsystable=''
conn_settings=''
translation_dll='',translation_option=''
conn = 134611560, SQLConnect(DSN='PostgreSQL', UID='tgl', PWD='doh')
SQLConnect- calling CC_connect...
Global Options: fetch=100, socket=4096, unknown_sizes=0,
max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=0, use_declarefetch=1
text_as_longvarchar=1, unknowns_as_longvarchar=0,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings=''
conn=134611560, query=' '
SQLConnect- return SQL_SUCCESS
golem> cat mylog.log
**** in SQLAllocEnv **
** exit SQLAllocEnv: phenv = 134611544 **
**** SQLAllocConnect: henv = 134611544, conn = 134611560
EN_add_connection: self = 134611544, conn = 134611560
added at i =0, conn->henv = 134611544, conns[i]->henv = 134611544
gpps- try opening /home/tgl/.odbc.ini
gpps- look in file /home/tgl/.odbc.ini section PostgreSQL for field
Description
<snip lots of debugging statements for reading the .ini file>
gpps- found section ODBC
gpps- check key InstallDir
CC_connect(): DSN = 'PostgreSQL', server = 'localhost', port = '5432',
database = 'test', username = 'tgl', password='doh'
connecting to the server socket...
connection to the server socket succeeded.
sizeof startup packet = 292
sent the authentication block.
sent the authentication block successfully.
gonna do authentication
read 5, global_socket_buffersize=4096
auth got 'R'
areq = 0
sending an empty query...
send_query(): conn=134611560, query=' '
send_query: done sending query
read 2, global_socket_buffersize=4096
send_query: got id = 'I'
in QR_Constructor
exit QR_Constructor
QResult: in DESTRUCTOR
QResult: free memory in, fcount=0
QResult: free memory out
QResult: exit DESTRUCTOR
empty query seems to be OK.
**** SQLAllocStmt: hdbc = 134611560, stmt = 134626288
CC_add_statement: self=134611560, stmt=134626288
Sending Initial Connection query: 'set DateStyle to 'ISO'; set geqo to
'OFF''
**** SQLExecDirect: hstmt=134626288, statement='set DateStyle to 'ISO';
set geqo to 'OFF''
SQLExecDirect: calling SQLExecute
**** enter SQLFreeStmt: hstmt=134626288, fOption=1
SC_Destructor: self=134626288, self->result=0, self->hdbc=134611560
SC_free_params: ENTER, self=134626288
SC_Destructor: EXIT
**** SQLAllocStmt: hdbc = 134611560, stmt = 134626288
CC_add_statement: self=134611560, stmt=134626288
**** SQLExecDirect: hstmt=134626288, statement='select oid from pg_type
where typname='lo''
SQLExecDirect: calling SQLExecute
**** enter SQLFreeStmt: hstmt=134626288, fOption=1
SC_Destructor: self=134626288, self->result=0, self->hdbc=134611560
SC_free_params: ENTER, self=134626288
SC_Destructor: EXIT
CC_connect- returning SQL_SUCCESS
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-08-01 19:48 ` David Hartwig <daybee@bellatlantic.net>
1998-08-02 04:37 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1 sibling, 1 reply; 16+ messages in thread
From: David Hartwig @ 1998-08-01 19:48 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: MrLinux@applix.com, Aleksey Demakov <avd@gcom.ru>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
Thomas G. Lockhart wrote:
> OK, I've gotten a ways farther; here is the current status on the
> ApplixWare->Postgres interface via iODBC using the Insight driver:
>
Tom,
In case your not aware, Byron is on vacation. He will be back on the 10th. He
will assist you (if you need assistance) in getting driver working with Applix. when
he returns.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 19:48 ` Re: [INTERFACES] psqlodbc David Hartwig <daybee@bellatlantic.net>
@ 1998-08-02 04:37 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-08-02 04:37 UTC (permalink / raw)
To: David Hartwig <daybee@bellatlantic.net>; +Cc: MrLinux@applix.com, Aleksey Demakov <avd@gcom.ru>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces
> > OK, I've gotten a ways farther; here is the current status on the
> > ApplixWare->Postgres interface via iODBC using the Insight driver:
> In case your not aware, Byron is on vacation. He will be back on the
> 10th. He will assist you (if you need assistance) in getting driver
> working with Applix. when he returns.
Yes, Byron announced his vacation on the list, which was helpful. I'm
making progress (at least so far) in areas which aren't visible to Byron
since they involve Applix/iodbc/psqlodbc interactions (and are happening
on a Unix box rather than a Windows machine), but I am looking forward
to his advice when he returns.
Been copying him so he gets the hint when he gets back :)
Anyway, I'm going to try running the backend in full debug mode which
might give some clues. I hadn't considered the fact that the "broken
pipe" message might actually be a frontend/backend hangup rather than an
internal Applix/iodbc problem. So there may be some Postgres packet
debugging in our future :/
btw, we apparently missed the window to be included in the next Applix
release, but that shouldn't matter much; we can post the driver stuff on
the Postgres web site and the Applix mailing list can announce it.
Just hope we don't find any fundamental problems on the Applix side,
though we shouldn't since it apparently already works with MySQL.
- Tom
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-08-02 14:51 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 17:08 ` Re: [INTERFACES] psqlodbc David Hartwig <daybee@bellatlantic.net>
1 sibling, 1 reply; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-08-02 14:51 UTC (permalink / raw)
To: Aleksey Demakov <avd@gcom.ru>; David Hartwig <daybee@bellatlantic.net>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces; +Cc: MrLinux@applix.com
> 3) The driver appears to successfully complete a few of the
> transactions involved in starting up the database connection,
> including one or two queries. It returns from SQLConnect() with a
> SQL_SUCCESS return code.
> 4) After that point Applix reports a "broken pipe". Log info from the
> "psqlodbc" and "mylog" debugging files is at the end of the mail. It
> looks like SQLConnect() is returning, but I don't know what should
> happen next to see where things are bombing out.
It turns out that the backend reports "reaping dead processes" without
showing any successful transactions other than (perhaps) a successful
plain connection. So, it appears that the two or three queries embedded
into SQLConnect()/CC_connect() are not actually succeeding, or even
getting to the backend properly.
Looks like it would help to have Byron involved, so I will move back to
working on docs for a few days.
btw, I've only just started looking at the fe/be code, but istm that it
would be really nice if libpq-fe could fully support the WIN32 interface
or if psqlodbc could use libpq-fe when on a Unix box. Some guy in Russia
has a driver which uses libpq-fe and the code looks like it has the same
lineage as Byron's code (before Byron started working on it). Where does
this code come from? Byron's code gives credit to Christian Czezatke and
Dan McGuirk but the "iodbc project" driver doesn't.
- Tom
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 14:51 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
@ 1998-08-02 17:08 ` David Hartwig <daybee@bellatlantic.net>
1998-08-02 19:33 ` Re: [INTERFACES] psqlodbc Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 1 reply; 16+ messages in thread
From: David Hartwig @ 1998-08-02 17:08 UTC (permalink / raw)
To: Thomas G. Lockhart <lockhart@alumni.caltech.edu>; +Cc: Aleksey Demakov <avd@gcom.ru>; Byron Nikolaidis <byronn@insightdist.com>; pgsql-interfaces; MrLinux@applix.com
Thomas G. Lockhart wrote:
> It turns out that the backend reports "reaping dead processes" without
> showing any successful transactions other than (perhaps) a successful
> plain connection. So, it appears that the two or three queries embedded
> into SQLConnect()/CC_connect() are not actually succeeding, or even
> getting to the backend properly.
>
I am not sure how fresh your source is, but I do recall Byron making some
tweaks in the initial connection queries recently. We'll wait and see.
> btw, I've only just started looking at the fe/be code, but istm that it
> would be really nice if libpq-fe could fully support the WIN32 interface
> or if psqlodbc could use libpq-fe when on a Unix box. Some guy in Russia
> has a driver which uses libpq-fe and the code looks like it has the same
> lineage as Byron's code (before Byron started working on it). Where does
> this code come from? Byron's code gives credit to Christian Czezatke and
> Dan McGuirk but the "iodbc project" driver doesn't.
>
Don't know about the Russian dude, but the we completely rewrote the the
front-end section in the driver. We did not (and still do not) like the
way libpq consumes the entire query result into front-end memory before
returning control to the application. This make large queries slow and
sometimes impossible. However, with the patches that Bruce and Vadim are
working on for multiple ORs (many thanks) this may become a moot issue.
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 14:51 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 17:08 ` Re: [INTERFACES] psqlodbc David Hartwig <daybee@bellatlantic.net>
@ 1998-08-02 19:33 ` Tom Lane <tgl@sss.pgh.pa.us>
0 siblings, 0 replies; 16+ messages in thread
From: Tom Lane @ 1998-08-02 19:33 UTC (permalink / raw)
To: David Hartwig <daybee@bellatlantic.net>; +Cc: pgsql-interfaces
David Hartwig <daybee@bellatlantic.net> writes:
> We did not (and still do not) like the
> way libpq consumes the entire query result into front-end memory before
> returning control to the application. This make large queries slow and
> sometimes impossible.
With the new PQsendQuery/PQgetResult API, it would not take very much
work to address this objection. The application could set a limit on
the number of tuples to be returned per PGresult (maybe about 100 would
reasonable), and then use a loop calling PQgetResult to fetch all the
tuples of a large query. We'd probably want to add a new boolean flag
"end of query/not end of query" to PGresult so that one could use this
feature even when sending multiple SELECTs in one sendQuery.
Rather than make the limit a persistent setting of a PGconn object,
I'd be inclined to add it as a parameter to PQgetResult (I think it's
not too late to change the calling sequence for PQgetResult, since it
hasn't yet seen the light of day in any formal release). Otherwise
PQexec might start behaving unexpectedly in an application that contains
a mixture of old-style PQexec calls and new-style PQsendQuery/getResult.
If the memory consumption issue is a hot button for anyone who is using
(or would use) libpq, I'll see if I can squeeze this in for 6.4. I assume
the psqlodbc guys will stick to their own code anyway.
regards, tom lane
^ permalink raw reply [nested|flat] 16+ messages in thread
* PSQLODBC
@ 1998-11-03 10:01 Jose' Soares <jose@sferacarta.com>
0 siblings, 0 replies; 16+ messages in thread
From: Jose' Soares @ 1998-11-03 10:01 UTC (permalink / raw)
To: pgsql-interfaces
Hi,
I have this problem using MSACCESS and PSQLODBC:
--------------------------------------------------------
MSACCESS raised an invalid page error on PSQLODBC.DLL
module in 0137:03938831.
Registers:
EAX=03510001 CS=0137 EIP=03938831 EFLGS=00010246
EBX=0351185c SS=013f ESP=0062e558 EBP=0062e57c
ECX=00000000 DS=013f ESI=039964e8 FS=28d7
EDX=03511d90 ES=013f EDI=00000001 GS=0000
Bytes at address CS:EIP:
8b 06 85 c0 74 4f 56 50 e8 d2 e1 ff ff 83 c4 08
Stack's image:
03511a5c 6a98303d 039964e8 00000001 00d00000 03511614 1b481050 00000000
00000000 0062e5d8 6a982f71 03511a5c 00000001 00000010 00c9dac4 03511614
------------------------------------------------
This is my log:
----------PSQLODBC.LOG------------------
conn=86835320, SQLDriverConnect(
in)='DSN=PostgreSQL;UID=;DATABASE=hygea;Marco;PWD=;',
fDriverCompletion=1
DSN info:
DSN='PostgreSQL',server='verde',port='5432',dbase='hygea',user='marco',passwd=''
readonly='0',protocol='',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings='set ksqo to 'on';'
translation_dll='',translation_option=''
conn=86835320,
SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde;PORT=5432;UID=marco;PWD=;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=1;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b'
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=2, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=1, use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=1,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings='
'
conn=86835320, query=' '
conn=86835320, query='set DateStyle to 'ISO''
conn=86835320, query='set geqo to 'OFF''
conn=86835320, query='
'
conn=86835320, query='set ksqo to 'on''
conn=86835320, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=86835320, query='SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR: msysconf: Table does not
exist.'
STATEMENT ERROR: func=SC_execute, desc='', errnum=1, errmsg='Error
while
executing the query'
------------------------------------------------------------
hdbc=86835320, stmt=86849812, result=0
manual_result=0, prepare=0, internal=0
bindings=0, bindings_allocated=0
parameters=0, parameters_allocated=0
statement_type=0, statement='SELECT Config, nValue
FROM
MSysConf'
stmt_with_params='SELECT Config, nValue FROM MSysConf'
data_at_exec=-1, current_exec_param=-1, put_data=0
currTuple=-1, current_col=-1, lobj_fd=-1
maxRows=0, rowset_size=1, keyset_size=0,
cursor_type=0,
scroll_concurrency=1
cursor_name='SQL_CUR052D3914'
----------------QResult Info
-------------------------------
CONN ERROR: func=SC_execute, desc='', errnum=10, errmsg='ERROR:
msysconf: Table does not exist.'
------------------------------------------------------------
henv=87887764, conn=86835320, status=1, num_stmts=16
sock=87887780, stmts=87883908, lobj_type=-999
---------------- Socket Info
-------------------------------
socket=58, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=86841612, buffer_out=86845712
buffer_filled_in=42, buffer_filled_out=0, buffer_read_in=42
conn=86835320, query='SELECT "codice" ,"nome_usl" ,"nome_distretto"
,"istat" ,"indirizzo" FROM "distretti" WHERE
NOT(("ordine_presentazione" = '' ) ) ORDER BY "ordine_presentazione" '
[ fetched 3 rows ]
conn=86920344, SQLDriverConnect(
in)='DSN=PostgreSQL;UID=;DATABASE=hygea;Marco;PWD=;',
fDriverCompletion=1
DSN info:
DSN='PostgreSQL',server='verde',port='5432',dbase='hygea',user='marco',passwd=''
readonly='0',protocol='',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings='set ksqo to 'on';'
translation_dll='',translation_option=''
conn=86920344,
SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde;PORT=5432;UID=marco;PWD=;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=1;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b'
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=2, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=1, use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=1,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings='
'
conn=86920344, query=' '
conn=86920344, query='set DateStyle to 'ISO''
conn=86920344, query='set geqo to 'OFF''
conn=86920344, query='
'
conn=86920344, query='set ksqo to 'on''
conn=86920344, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=86920344, query='SELECT "ragione_sociale" FROM "utenti" WHERE
("azienda" = '006SR031' ) '
[ fetched 1 rows ]
conn=86920344, query='SELECT "prestazioni"."progressivo"
,"prestazioni"."azienda" ,"prestazioni"."data"
,"prestazioni"."operatore1" ,"prestazioni"."operatore2"
,"prestazioni"."operatore3" ,"prestazioni"."n_accessi"
,"prestazioni"."in_corso" ,"risanamento"."specie"
,"risanamento"."tipo_profilassi" ,"risanamento"."generale"
,"risanamento"."capi_negativi" ,"risanamento"."capi_dubbi"
,"risanamento"."capi_positivi" FROM "prestazioni","risanamento" WHERE
((("prestazioni"."azienda" = '006SR031' ) AND
("risanamento"."progressivo" = "prestazioni"."progressivo" ) ) AND (
'01' = "risanamento"."specie" ) ) '
[ fetched 9 rows ]
conn=86920344, query='SELECT "prestazioni"."progressivo"
,"prestazioni"."azienda" ,"prestazioni"."data"
,"prestazioni"."operatore1" ,"prestazioni"."operatore2"
,"prestazioni"."operatore3" ,"prestazioni"."n_accessi"
,"prestazioni"."in_corso" ,"risanamento"."specie"
,"risanamento"."tipo_profilassi" ,"risanamento"."generale"
,"risanamento"."capi_negativi" ,"risanamento"."capi_dubbi"
,"risanamento"."capi_positivi" FROM "prestazioni","risanamento" WHERE
((("prestazioni"."azienda" = '006SR031' ) AND
("risanamento"."progressivo" = "prestazioni"."progressivo" ) ) AND (
'01' = "risanamento"."specie" ) ) '
[ fetched 9 rows ]
conn=86835320, query='SELECT
"FrmPrestazioni"."distretto","FrmPrestazioni"."progressivo","FrmPrestazioni"."specie","FrmPrestazioni"."tipo_profilassi"
FROM "risanamento" "FrmPrestazioni" WHERE (("distretto" = '' ) AND
("progressivo" = NULL ) ) '
[ fetched 0 rows ]
conn=86835320, query='SELECT "contatore" FROM "contatori" WHERE
("tipologia" = 'SOPRA' ) '
[ fetched 1 rows ]
conn=86835320, query='SELECT
"prestazioni"."distretto","prestazioni"."progressivo" FROM
"prestazioni"
WHERE ("progressivo" = 137 ) '
[ fetched 0 rows ]
conn=86835320, query='SELECT "azienda" ,"ragione_sociale" FROM
"utenti"
WHERE ("dpr317" = 'S' ) ORDER BY "ragione_sociale" '
[ fetched 765 rows ]
conn=86962288, SQLDriverConnect(
in)='DSN=PostgreSQL;UID=marco;PWD=;DATABASE=hygea;SERVER=verde;PORT=5432;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b;',
fDriverCompletion=0
DSN info:
DSN='PostgreSQL',server='verde',port='5432',dbase='hygea',user='marco',passwd=''
readonly='0',protocol='',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings='set ksqo to 'on';'
translation_dll='',translation_option=''
conn=86962288,
SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde;PORT=5432;UID=marco;PWD=;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b'
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=2, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=1, use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=1,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings='
'
conn=86962288, query=' '
conn=86962288, query='set DateStyle to 'ISO''
conn=86962288, query='set geqo to 'OFF''
conn=86962288, query='
'
conn=86962288, query='set ksqo to 'on''
conn=86962288, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=86962288, query='SELECT
"FrmPrestazioni"."distretto","FrmPrestazioni"."progressivo","FrmPrestazioni"."specie","FrmPrestazioni"."tipo_profilassi"
FROM "risanamento" "FrmPrestazioni" WHERE (("distretto" = 'RA10' ) AND
("progressivo" = 137 ) ) '
[ fetched 0 rows ]
conn=86962288, SQLDisconnect
conn=86962288, SQLDriverConnect(
in)='DSN=PostgreSQL;UID=marco;PWD=;DATABASE=hygea;SERVER=verde;PORT=5432;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b;',
fDriverCompletion=0
DSN info:
DSN='PostgreSQL',server='verde',port='5432',dbase='hygea',user='marco',passwd=''
readonly='0',protocol='',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings='set ksqo to 'on';'
translation_dll='',translation_option=''
conn=86962288,
SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde;PORT=5432;UID=marco;PWD=;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b'
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=2, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=1, use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=1,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings='
'
conn=86962288, query=' '
conn=86962288, query='set DateStyle to 'ISO''
conn=86962288, query='set geqo to 'OFF''
conn=86962288, query='
'
conn=86962288, query='set ksqo to 'on''
conn=86962288, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=86962288, query='SELECT "contatore" FROM "contatori" WHERE
("tipologia" = 'SOPRA' ) '
[ fetched 1 rows ]
conn=86962288, SQLDisconnect
conn=86962288, SQLDriverConnect(
in)='DSN=PostgreSQL;UID=marco;PWD=;DATABASE=hygea;SERVER=verde;PORT=5432;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b;',
fDriverCompletion=0
DSN info:
DSN='PostgreSQL',server='verde',port='5432',dbase='hygea',user='marco',passwd=''
readonly='0',protocol='',showoid='0',fakeoidindex='0',showsystable='0'
conn_settings='set ksqo to 'on';'
translation_dll='',translation_option=''
conn=86962288,
SQLDriverConnect(out)='DSN=PostgreSQL;DATABASE=hygea;SERVER=verde;PORT=5432;UID=marco;PWD=;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS=set+ksqo+to+%27on%27%3b'
Global Options: Version='06.30.0250', fetch=100, socket=4096,
unknown_sizes=2, max_varchar_size=254, max_longvarchar_size=4094
disable_optimizer=1, unique_index=1, use_declarefetch=0
text_as_longvarchar=1, unknowns_as_longvarchar=1,
bools_as_char=1
extra_systable_prefixes='dd_;', conn_settings='
'
conn=86962288, query=' '
conn=86962288, query='set DateStyle to 'ISO''
conn=86962288, query='set geqo to 'OFF''
conn=86962288, query='
'
conn=86962288, query='set ksqo to 'on''
conn=86962288, query='select oid from pg_type where typname='lo''
[ fetched 0 rows ]
conn=86962288, query='BEGIN'
conn=86962288, query='UPDATE "contatori" SET contatore=137 WHERE
("tipologia" = 'SOPRA' ) '
conn=86962288, query='COMMIT'
conn=86962288, SQLDisconnect
------------------------------------------------------------------
Any ideas ?
Thanks, Jose'
^ permalink raw reply [nested|flat] 16+ messages in thread
* psqlodbc
@ 1998-11-25 09:30 Jose' Soares <jose@sferacarta.com>
1998-11-25 14:27 ` Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 1 reply; 16+ messages in thread
From: Jose' Soares @ 1998-11-25 09:30 UTC (permalink / raw)
To: pgsql-interfaces; +Cc: sferac@bo.nettuno.it
Hi all,
I have a problem with psqlodbc using M$access.
I created a query on M$access, with the following:
SELECT esito1, esito2
FROM brogliacci
WHERE esito1 IS NOT NULL OR esito2 IS NOT NULL;
When I tred to execute the query I had an
ODBC call failed message and then the connection was down.
Here an extract of psqlodbc.log file:
<DELETED>
---------------- Socket Info -------------------------------
socket=53, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=55122188, buffer_out=55126288
buffer_filled_in=42, buffer_filled_out=0, buffer_read_in=42
conn=55115896, query='SELECT "brogliacci"."esito1","brogliacci"."esito2"
FROM "brogliacci" WHERE (NOT(("esito1" IS NULL ) ) OR NOT(("esito2" IS
NULL ) ) ) '
STATEMENT ERROR: func=SC_execute, desc='', errnum=1, errmsg='Error while
executing the query'
------------------------------------------------------------
hdbc=55115896, stmt=55130388, result=0
<DELETED>
I see that psqlodbc translate the query as:
SELECT "brogliacci"."esito1","brogliacci"."esito2"
FROM "brogliacci"
WHERE (NOT(("esito1" IS NULL ) ) OR NOT(("esito2" IS NULL ) ) )
I don't know if this syntax is standard but anyway PostgreSQL understand
this syntax
except when the sentence contains the OR operator.
EXAMPLES:
SELECT esito1, esito2 FROM brogliacci
WHERE esito1 Is Not Null OR esito2 Is Not Null;
esito1|esito2
------+------
(0 rows)
SELECT "brogliacci"."esito1","brogliacci"."esito2" FROM "brogliacci"
WHERE (NOT(("esito1" IS NULL ) ) );
esito1|esito2
------+------
(0 rows)
SELECT "brogliacci"."esito1","brogliacci"."esito2" FROM "brogliacci"
WHERE (NOT(("esito1" IS NULL ) ) AND NOT(("esito2" IS NULL ) ) );
esito1|esito2
------+------
(0 rows)
SELECT "brogliacci"."esito1","brogliacci"."esito2" FROM "brogliacci"
WHERE (NOT(("esito1" IS NULL ) ) OR NOT(("esito2" IS NULL ) ) );
pqReadData() -- backend closed the channel unexpectedly.
This probably means the backend terminated abnormally before or
while pr
ocessing the request.
We have lost the connection to the backend, so further processing is
impossible.
Terminating.
Should it be considered a bug ?
Please replay to sferac@bo.nettuno.it because I have problems with
jose@sferacarta.com, Thanks
-Jose'-
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-11-25 09:30 psqlodbc Jose' Soares <jose@sferacarta.com>
@ 1998-11-25 14:27 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
0 siblings, 0 replies; 16+ messages in thread
From: Thomas G. Lockhart @ 1998-11-25 14:27 UTC (permalink / raw)
To: sferac@bo.nettuno.it; +Cc: pgsql-interfaces
> SELECT esito1, esito2
> FROM brogliacci
> WHERE esito1 IS NOT NULL OR esito2 IS NOT NULL;
> When I tred to execute the query I had an
> ODBC call failed message and then the connection was down.
I believe that Bruce and Vadim just recently fixed this (you have an
index on the table? It might work if you remove the index). Bruce is
gone for a few days for the U.S. Thanksgiving holiday, but may have more
info when he returns...
- Tom
^ permalink raw reply [nested|flat] 16+ messages in thread
* psqlodbc
@ 1998-11-27 10:26 Jose' Soares <jose@sferacarta.com>
1998-11-30 13:53 ` Re: [INTERFACES] psqlodbc David Hartwig <daveh@insightdist.com>
0 siblings, 1 reply; 16+ messages in thread
From: Jose' Soares @ 1998-11-27 10:26 UTC (permalink / raw)
To: daveh@insightdist.com; +Cc: pgsql-interfaces
Hi David and Byron,
I have another problem with psqlodbc using m$access.
I have the following query:
SELECT azienda, attivita, specifica, inizio_attivita, fine_attivita
FROM ATTIVITA WHERE attivita<='10'
UNION ALL
SELECT azienda, attivita, specifica, inizio_attivita, fine_attivita
FROM figure
INNER JOIN attivita ON figure.codice_figura = attivita.azienda
WHERE figure.tipo='A';
Seems that psqlodbc translate it in a wrong way because it enclose
SELECTS between () and PostgreSQL doesn't understands (SELECT ....):
Here the log file:
-------------------------------------------------------------------
STATEMENT ERROR: func=SC_execute, desc='', errnum=1, errmsg='Error while
executi
ng the query'
------------------------------------------------------------
hdbc=54067320, stmt=54081812, result=0
manual_result=0, prepare=0, internal=0
bindings=0, bindings_allocated=0
parameters=0, parameters_allocated=0
statement_type=-1, statement='(SELECT "azienda"
,"attivita" ,"s
pecifica" ,"inizio_attivita" ,"fine_attivita" FROM "attivita" WHERE
("attivita"
<= '10' ) ) UNION ALL (SELECT "attivita"."azienda"
,"attivita"."attivita" ,"att
ivita"."specifica" ,"attivita"."inizio_attivita"
,"attivita"."fine_attivita" FR
OM "figure","attivita" WHERE (("figure"."tipo" = 'A' ) AND
("figure"."codice_fig
ura" = "attivita"."azienda" ) ) )'
stmt_with_params=''
data_at_exec=-1, current_exec_param=-1, put_data=0
currTuple=-1, current_col=-1, lobj_fd=-1
maxRows=0, rowset_size=1, keyset_size=0, cursor_type=0,
scroll_
concurrency=1
cursor_name='SQL_CUR03393914'
-----------------------------------------------------------------------
Thanks for any help
-Jose'-
^ permalink raw reply [nested|flat] 16+ messages in thread
* Re: [INTERFACES] psqlodbc
1998-11-27 10:26 psqlodbc Jose' Soares <jose@sferacarta.com>
@ 1998-11-30 13:53 ` David Hartwig <daveh@insightdist.com>
0 siblings, 0 replies; 16+ messages in thread
From: David Hartwig @ 1998-11-30 13:53 UTC (permalink / raw)
To: sferac@bo.nettuno.it; +Cc: pgsql-interfaces
The driver does not rewrite queries. This would be the wisdom of the MS
Jet Engine. My guess is, that the backend should handle this statement:
daveh=> (select 1) union all (select 2);
ERROR: parser: parse error at or near "("
In the meantime, can you construct this as a pass-through query?
Jose' Soares wrote:
> Hi David and Byron,
>
> I have another problem with psqlodbc using m$access.
> I have the following query:
>
> SELECT azienda, attivita, specifica, inizio_attivita, fine_attivita
> FROM ATTIVITA WHERE attivita<='10'
> UNION ALL
> SELECT azienda, attivita, specifica, inizio_attivita, fine_attivita
> FROM figure
> INNER JOIN attivita ON figure.codice_figura = attivita.azienda
> WHERE figure.tipo='A';
>
> Seems that psqlodbc translate it in a wrong way because it enclose
> SELECTS between () and PostgreSQL doesn't understands (SELECT ....):
> Here the log file:
> -------------------------------------------------------------------
> STATEMENT ERROR: func=SC_execute, desc='', errnum=1, errmsg='Error while
> executi
> ng the query'
>
> ------------------------------------------------------------
> hdbc=54067320, stmt=54081812, result=0
> manual_result=0, prepare=0, internal=0
> bindings=0, bindings_allocated=0
> parameters=0, parameters_allocated=0
> statement_type=-1, statement='(SELECT "azienda"
> ,"attivita" ,"s
> pecifica" ,"inizio_attivita" ,"fine_attivita" FROM "attivita" WHERE
> ("attivita"
> <= '10' ) ) UNION ALL (SELECT "attivita"."azienda"
> ,"attivita"."attivita" ,"att
> ivita"."specifica" ,"attivita"."inizio_attivita"
> ,"attivita"."fine_attivita" FR
> OM "figure","attivita" WHERE (("figure"."tipo" = 'A' ) AND
> ("figure"."codice_fig
> ura" = "attivita"."azienda" ) ) )'
> stmt_with_params=''
> data_at_exec=-1, current_exec_param=-1, put_data=0
> currTuple=-1, current_col=-1, lobj_fd=-1
> maxRows=0, rowset_size=1, keyset_size=0, cursor_type=0,
> scroll_
> concurrency=1
> cursor_name='SQL_CUR03393914'
> -----------------------------------------------------------------------
>
> Thanks for any help
>
> -Jose'-
^ permalink raw reply [nested|flat] 16+ messages in thread
end of thread, other threads:[~1998-11-30 13:53 UTC | newest]
Thread overview: 16+ messages (download: mbox mbox.gz follow: Atom feed)
-- links below jump to the message on this page --
1998-07-28 02:22 psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-28 06:45 ` Aleksey Demakov <avd@gcom.ru>
1998-07-30 05:10 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-31 02:44 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-07-31 15:27 Re: [INTERFACES] psqlodbc Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 17:08 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-01 19:48 ` David Hartwig <daybee@bellatlantic.net>
1998-08-02 04:37 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 14:51 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-08-02 17:08 ` David Hartwig <daybee@bellatlantic.net>
1998-08-02 19:33 ` Tom Lane <tgl@sss.pgh.pa.us>
1998-11-03 10:01 PSQLODBC Jose' Soares <jose@sferacarta.com>
1998-11-25 09:30 psqlodbc Jose' Soares <jose@sferacarta.com>
1998-11-25 14:27 ` Thomas G. Lockhart <lockhart@alumni.caltech.edu>
1998-11-27 10:26 psqlodbc Jose' Soares <jose@sferacarta.com>
1998-11-30 13:53 ` David Hartwig <daveh@insightdist.com>
This inbox is served by DDX for PostgreSQL; see mirroring instructions
for how to clone and mirror all data and code used for this inbox