No title
Hi!
I've applied the junkfilter because I want to use the ODBC-driver to
let
Access make some querys on a postgres-db.
But since this patch i can't Delete tuples anymore. A 'Delete from
table
where x=1;' will crash the backend. :-(
Any hints?
I tryed this with postgresql.6.3.2 with all patches and with no other
patches applied.
Gerald Fischer
Hi all,
domenica, 6 settembre 98, you wrote:
GF> Hi!
GF> I've applied the junkfilter because I want to use the ODBC-driver to
GF> let
GF> Access make some querys on a postgres-db.
GF> But since this patch i can't Delete tuples anymore. A 'Delete from
GF> table
GF> where x=1;' will crash the backend. :-(
GF> Any hints?
GF> I tryed this with postgresql.6.3.2 with all patches and with no other
GF> patches applied.
GF> Gerald Fischer
Now I have this problem too.
This is the second time for me. The other day (August 6)I sent an help message to the
list, because my backend crashed during a DELETE or a DROP DATABASE
statement. I had no response till Sept 2 and then I decide to re-install PostgreSQL.
It works well until today (Sept 7).
I'm working with ODBC and Access too.
Please help. I don't want to re-install PostgreSQL again.
Thanks in advance
Jose' mailto:sferac@bo.nettuno.it
Hi Jose, hi Hackers!
On Mon, 7 Sep 1998 17:09:04 +0200, Sferacarta Software wrote:
GF> I've applied the junkfilter because I want to use the ODBC-driver to
GF> let Access make some querys on a postgres-db.GF> But since this patch i can't Delete tuples anymore. A 'Delete from
GF> table where x=1;' will crash the backend. :-(GF> Any hints?
GF> I tryed this with postgresql.6.3.2 with all patches and with no other
GF> patches applied.
Now I have this problem too.
This is the second time for me. The other day (August 6)I sent an help message to the
list, because my backend crashed during a DELETE or a DROP DATABASE
statement. I had no response till Sept 2 and then I decide to re-install PostgreSQL.
It works well until today (Sept 7).I'm working with ODBC and Access too.
Please help. I don't want to re-install PostgreSQL again.
I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(
I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver can't connect to the database. The logfile
says:
----------------
conn=71501948, SQLDriverConnect( in)='DRIVER={PostgreSQL};', fDriverCompletion=1
conn=71501948, SQLDriverConnect(out)='DRIVER={PostgreSQL};DATABASE=test;SERVER=hp;PORT=5432;UID=gerald;PWD=av;READONLY=0;PROTOCOL=;FAKEOIDINDEX=0;SHOWOIDCOLUMN=
0;ROWVERSIONING=0;SHOWSYSTEMTABLES=0;CONNSETTINGS='
Global Options: fetch=100, socket=4096, unknown_sizes=0, max_varchar_size=255, 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=71501948, query=' '
conn=71501948, query='BEGIN'
conn=71501948, query='set DateStyle to 'ISO'; set geqo to 'OFF''
Command response: 'SET VARIABLE'
conn=71501948, query='declare SQL_CUR71516440 cursor for select oid from pg_type where typname='lo''
conn=71501948, query='fetch 100 in SQL_CUR71516440'
[ fetched 0 rows ]
conn=71501948, query='close SQL_CUR71516440'
conn=71501948, query='END'
conn=71501948, query='BEGIN'
conn=71501948, query='declare SQL_CUR71582124 cursor for select relname, usename, relhasrules from pg_class, pg_user where relkind = 'r' and relname !~ '^xinv[0-9]+' and int4out(usesysid) = int4out
(relowner) order by relname'
conn=71501948, query='fetch 100 in SQL_CUR71582124'
[ fetched 30 rows ]
conn=71501948, query='close SQL_CUR71582124'
conn=71501948, query='END'
conn=71501948, query='BEGIN'
conn=71501948, query='declare SQL_CUR71582124 cursor for select u.usename, c.relname, a.attname, a.atttypid,t.typname, a.attnum, a.attlen, a.atttypmod, a.attnotnull from pg_user u, pg_class c, pg_attribute
a, pg_type t where int4out(u.usesysid) = int4out(c.relowner) and c.oid= a.attrelid and a.atttypid = t.oid and (a.attnum > 0) and c.relname like 'test' order by attnum'
conn=71501948, query='fetch 100 in SQL_CUR71582124'
[ fetched 2 rows ]
STATEMENT ERROR: func=SQLFetch, desc='', errnum=3, errmsg='Null statement result in SQLFetch.'
------------------------------------------------------------
hdbc=0, stmt=71630847, result=0
manual_result=0, prepare=0, internal=0
bindings=0, bindings_allocated=0
parameters=0, parameters_allocated=0
statement_type=0, statement='(null)'
stmt_with_params=''
data_at_exec=0, current_exec_param=0, put_data=0
currTuple=0, current_col=0, lobj_fd=0
maxRows=0, rowset_size=0, keyset_size=0, cursor_type=0, scroll_concurrency=0
cursor_name=''
----------------QResult Info -------------------------------
INVALID CONNECTION HANDLE ERROR: func=SQLFetch, desc=''
STATEMENT ERROR: func=SQLColumns, desc='', errnum=0, errmsg='Null statement result in SQLFetch.'
------------------------------------------------------------
hdbc=71501948, stmt=71516440, result=72551288
manual_result=1, prepare=0, internal=0
bindings=72551372, bindings_allocated=14
parameters=0, parameters_allocated=0
statement_type=-2, statement='(null)'
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=''
----------------QResult Info -------------------------------
fields=72551348, manual_tuples=71647992, backend_tuples=0, tupleField=0, conn=0
fetch_count=0, fcount=0, num_fields=0, cursor='(null)'
message='(null)', command='(null)', notice='(null)'
status=0, inTuples=0
CONN ERROR: func=SQLColumns, desc='', errnum=0, errmsg=''
------------------------------------------------------------
henv=72548484, conn=71501948, status=1, num_stmts=16
sock=72548500, stmts=72548540, lobj_type=-999
---------------- Socket Info -------------------------------
socket=66, reverse=0, errornumber=0, errormsg='(null)'
buffer_in=71508240, buffer_out=71512340
buffer_filled_in=279, buffer_filled_out=0, buffer_read_in=279
conn=71501948, SQLDisconnect
conn=71501948, query='ABORT'
---------
And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
--------
conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR: msysconf: Table does not exist.'
--------
Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
Best regards,
Gerald Fischer
Import Notes
Resolved by subject fallback
Hi David!
On Mon, 07 Sep 1998 10:56:21 -0400, David Hartwig wrote:
First of all I want to thank you for your mail.
I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(
I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver
can't connect to the database. The logfile
says:
----------------The snapshot is very unstable at this time. 6.4 will not be official until after Oct.1. I would suggest not using it at this time
Well, I gave it a try.
---------
And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
--------
conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR: msysconf: Table does not exist.'
--------This is a normal error. MS Access always queries this table. It is not necessary for successful processing.
Typically M$ :-(
Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
It is difficult for me to figure out what your problem is. What we need is a reproducible sequence of events leading up to the crash.
Well, no problem :-) I can reproduce the crash. With or without the ODBC-Driver.
If you can reproduce the crash through the psql monitor, then we should work with that. No sense in adding an extra layer of complexity by working through the ODBC
driver.
The same goes for the junkfilter patch. The errors as you describe, do not point to the junkfilter patch. Admittedly, it is possible. See if the problem can be reproduced
without the junkfilter.
Ok, once again.
I've installed postgresql 6.3.2 with all patches from ftp.postgresql.org/pub/patches. It worked great, but I could not use the ODBC-Driver for stuff like order by and group by
(this is the bug where the junkfilter is a workaround, i think).
Therefore I installed the junkfilter, compiled again, and now I was able to order/group over the ODBC-Driver.
At this time I was happy :-), but than I wanted to make a destroyuser and the backend crashed. I thought it was the destroyuser-script, but then I tryed to make a simple
'delete from test;' and this crashed the backend, too :-(.
A few minutes ago we found out that triggers wont work, too.
Ok, I hoped it was another patch that does not like the junkfilter and I tryed to recompile a completly new version (only with the junkfilter applied). The same error occured.
Therefore I started today to give the snapshot a try, but it will not work together with the ODBC-Driver :-(.
Here a capture of psql:
-----
test=> \d test
Table = test
+----------------------------------+----------------------------------+-------+
| Field | Type | Length|
+----------------------------------+----------------------------------+-------+
| i | int4 | 4 |
| j | int4 | 4 |
+----------------------------------+----------------------------------+-------+
test=> select * from test;
i| j
---+---
100|100
(1 row)test=> delete from test;
PQexec() -- Request was sent to backend, but backend closed the channel before r
esponding.
This probably means the backend terminated abnormally before or while pr
ocessing the request.
test=>
test=> select * from test;
PQexec() -- There is no connection to the backend.
------
I hope you can help me, because the only thing I could try is to get another linux-distribution and try it with eg redhat (at the moment I use SuSE).
Best regards,
Gerald Fischer
PS: Sorry for my bad english...
Import Notes
Resolved by subject fallback
Gerald Fischer wrote:
Hi David!
On Mon, 07 Sep 1998 10:56:21 -0400, David Hartwig wrote:
First of all I want to thank you for your mail.
I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(
I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver
can't connect to the database. The logfile
says:
----------------The snapshot is very unstable at this time. 6.4 will not be official until after Oct.1. I would suggest not using it at this time
Well, I gave it a try.
---------
And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
--------
conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR: msysconf: Table does not exist.'
--------This is a normal error. MS Access always queries this table. It is not necessary for successful processing.
Typically M$ :-(
Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
It is difficult for me to figure out what your problem is. What we need is a reproducible sequence of events leading up to the crash.
Well, no problem :-) I can reproduce the crash. With or without the ODBC-Driver.
If you can reproduce the crash through the psql monitor, then we should work with that. No sense in adding an extra layer of complexity by working through the ODBC
driver.
The same goes for the junkfilter patch. The errors as you describe, do not point to the junkfilter patch. Admittedly, it is possible. See if the problem can be reproduced
without the junkfilter.
Ok, once again.
I've installed postgresql 6.3.2 with all patches from ftp.postgresql.org/pub/patches. It worked great, but I could not use the ODBC-Driver for stuff like order by and group by
(this is the bug where the junkfilter is a workaround, i think).
Correct. You may want to make sure you have the latest Jet Engine from M$. That are serious bugs in older versions. See our FAQ at
http://www.insightdist.com/psqlodbc This will not solve our current problem.
Therefore I installed the junkfilter, compiled again, and now I was able to order/group over the ODBC-Driver.
At this time I was happy :-), but than I wanted to make a destroyuser and the backend crashed. I thought it was the destroyuser-script, but then I tryed to make a simple
'delete from test;' and this crashed the backend, too :-(.
A few minutes ago we found out that triggers wont work, too.
Ok, I hoped it was another patch that does not like the junkfilter and I tryed to recompile a completly new version (only with the junkfilter applied). The same error occured.
Hmm... Something is not right here. I have not problem on either AIX or Caldera Linux and I know others are using the patch without any problems. I doubt if I are going to be
able to resolve this soon. I am juggling too many things right now. Our best bet may be to wait until 6.4
Therefore I started today to give the snapshot a try, but it will not work together with the ODBC-Driver :-(.
Here a capture of psql:
-----
test=> \d testTable = test +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | i | int4 | 4 | | j | int4 | 4 | +----------------------------------+----------------------------------+-------+ test=> select * from test; i| j ---+--- 100|100 (1 row)test=> delete from test;
PQexec() -- Request was sent to backend, but backend closed the channel before r
esponding.
This probably means the backend terminated abnormally before or while pr
ocessing the request.
test=>
test=> select * from test;
PQexec() -- There is no connection to the backend.
------I hope you can help me, because the only thing I could try is to get another linux-distribution and try it with eg redhat (at the moment I use SuSE).
I am not a Linux guru. So I don't have a clue a to weather this is an issue.
PS: Sorry for my bad english...
It way better that my second language.
daybee@bellatlantic.net said:
Correct. You may want to make sure you have the latest Jet Engine
from M$. That are serious bugs in older versions. See our FAQ at
http://www.insightdist.com/psqlodbc This will not solve our
current problem.
David,
Could you please post some more details on which is the latest version of Jet
and where it is hidden among all of the hype at www. microsoft.com.
Cheers and thanks,
Stephen.
========================================================================
Stephen Davies Consulting scldad@sdc.com.au
Adelaide, South Australia. Voice: 61-8-82728863
Computing & Network solutions. Fax: 61-8-82741015
Hi David!
On Mon, 07 Sep 1998 17:48:52 -0400, David Hartwig wrote:
Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
It is difficult for me to figure out what your problem is. What we need is a reproducible sequence of events leading up to the
crash.
Well, no problem :-) I can reproduce the crash. With or without the ODBC-Driver.
If you can reproduce the crash through the psql monitor, then we should work with that. No sense in adding an extra layer of
complexity by working through the ODBC
driver.
The same goes for the junkfilter patch. The errors as you describe, do not point to the junkfilter patch. Admittedly, it is
possible. See if the problem can be reproduced
without the junkfilter.
Ok, once again.
I've installed postgresql 6.3.2 with all patches from ftp.postgresql.org/pub/patches. It worked great, but I could not use the
ODBC-Driver for stuff like order by and group by
(this is the bug where the junkfilter is a workaround, i think).
Correct. You may want to make sure you have the latest Jet Engine from M$.
That are serious bugs in older versions. See our FAQ at
I've got 3.5, as far as I remember (downloaded from MS some days ago).
http://www.insightdist.com/psqlodbc This will not solve our current problem.
Thats right :-(
Therefore I installed the junkfilter, compiled again, and now I was able to order/group over the ODBC-Driver.
At this time I was happy :-), but than I wanted to make a destroyuser and the backend crashed. I thought it was the
destroyuser-script, but then I tryed to make a simple
'delete from test;' and this crashed the backend, too :-(.
A few minutes ago we found out that triggers wont work, too.
Ok, I hoped it was another patch that does not like the junkfilter and I tryed to recompile a completly new version (only with the
junkfilter applied). The same error occured.
Hmm... Something is not right here. I have not problem on either AIX or Caldera Linux and I know others are using the patch
without any problems. I doubt if I are going to be
able to resolve this soon. I am juggling too many things right now. Our best bet may be to wait until 6.4
I other words, I should try the snapshot every day or connect me to the cvs and hope for a working system... :-@
I hope you can help me, because the only thing I could try is to get another linux-distribution and try it with eg redhat (at the
moment I use SuSE).
I am not a Linux guru. So I don't have a clue a to weather this is an issue.
Maybe someone could send me his working binarys to determine if it is a compiler problem, or a 'distribution' problem. It might be an
old lib or something like this?!
PS: Sorry for my bad english...
It way better that my second language.
Thanks.
Best regards,
Gerald Fischer
Import Notes
Resolved by subject fallback
Hello David,
luned�, 7 settembre 98, you wrote:
DH> Gerald Fischer wrote:
Hi David!
On Mon, 07 Sep 1998 10:56:21 -0400, David Hartwig wrote:
First of all I want to thank you for your mail.
I reinstalled Postgresql with this patch about 10 times in the last 2 days, but without success. :-(
I tried now to use the snapshot, and it compiled nearly without problems (in /src/interfaces/ecpg/preproc/preproc.y is a ';' missing on line 1562), but the ODBC-Driver
can't connect to the database. The logfile
says:
----------------The snapshot is very unstable at this time. 6.4 will not be official until after Oct.1. I would suggest not using it at this time
Well, I gave it a try.
---------
And with the snapshot of sept. 6th, it complains about a missing MSysConf-Table. :-(
--------
conn=71501948, query='declare SQL_CUR71516440 cursor for SELECT Config, nValue FROM MSysConf'
ERROR from backend during send_query: 'ERROR: msysconf: Table does not exist.'
--------This is a normal error. MS Access always queries this table. It is not necessary for successful processing.
Typically M$ :-(
Please help, because I would need a running system tomorrow :-( (For the moment it will do it without delete, but not for ever).
It is difficult for me to figure out what your problem is. What we need is a reproducible sequence of events leading up to the crash.
Well, no problem :-) I can reproduce the crash. With or without the ODBC-Driver.
If you can reproduce the crash through the psql monitor, then we should work with that. No sense in adding an extra layer of complexity by working through the ODBC
driver.
The same goes for the junkfilter patch. The errors as you describe, do not point to the junkfilter patch. Admittedly, it is possible. See if the problem can be reproduced
without the junkfilter.
Ok, once again.
I've installed postgresql 6.3.2 with all patches from ftp.postgresql.org/pub/patches. It worked great, but I could not use the ODBC-Driver for stuff like order by and group by
(this is the bug where the junkfilter is a workaround, i think).
DH> Correct. You may want to make sure you have the latest Jet Engine from M$. That are serious bugs in older versions. See our FAQ at
DH> http://www.insightdist.com/psqlodbc This will not solve our current problem.
Therefore I installed the junkfilter, compiled again, and now I was able to order/group over the ODBC-Driver.
At this time I was happy :-), but than I wanted to make a destroyuser and the backend crashed. I thought it was the destroyuser-script, but then I tryed to make a simple
'delete from test;' and this crashed the backend, too :-(.
A few minutes ago we found out that triggers wont work, too.
Ok, I hoped it was another patch that does not like the junkfilter and I tryed to recompile a completly new version (only with the junkfilter applied). The same error occured.
DH> Hmm... Something is not right here. I have not problem on either AIX or Caldera Linux and I know others are using the patch without any problems. I doubt if I are going to be
DH> able to resolve this soon. I am juggling too many things right now. Our best bet may be to wait until 6.4
Therefore I started today to give the snapshot a try, but it will not work together with the ODBC-Driver :-(.
Here a capture of psql:
-----
test=> \d testTable = test +----------------------------------+----------------------------------+-------+ | Field | Type | Length| +----------------------------------+----------------------------------+-------+ | i | int4 | 4 | | j | int4 | 4 | +----------------------------------+----------------------------------+-------+ test=> select * from test; i| j ---+--- 100|100 (1 row)test=> delete from test;
PQexec() -- Request was sent to backend, but backend closed the channel before r
esponding.
This probably means the backend terminated abnormally before or while pr
ocessing the request.
test=>
test=> select * from test;
PQexec() -- There is no connection to the backend.
------I hope you can help me, because the only thing I could try is to get
another linux-distribution and try it with eg redhat (at the moment I use SuSE).
I'm using Debian distribution and I have exactly the same problem. The
first time, it was a couple of weeks ago, then I recompiled and
reinstalled PostgreSQL and I solved my problem for a few days, but
now I have this error again.
I can't surely connect this error with the junkfilter patch but I can't
discard this possibility because I'm been using v-6.3.2 from the beginning
of its delivery, with no problems except lately after I applied this patch.
Best regards,
Jose' mailto:sferac@bo.nettuno.it
Stephen Davies wrote:
daybee@bellatlantic.net said:
Correct. You may want to make sure you have the latest Jet Engine
from M$. That are serious bugs in older versions. See our FAQ at
http://www.insightdist.com/psqlodbc This will not solve our
current problem.David,
Could you please post some more details on which is the latest version of Jet
and where it is hidden among all of the hype at www. microsoft.com.
The link is on the our FAQ. M$ will first prompt you for some basic demographics tidbits. Like:
"Do you have any pets? If so, do they enjoy M$ products as much as you do."
On the FAQ see: 3. Why does MS Access sometimes complain about a GROUP BY or ORDER BY not being
in the target list?