[BUGS] Bug #559: MACADDR type & 00:00:00:00:00:00
Michael Handler ([EMAIL PROTECTED]) reports a bug with a severity of 3
The lower the number the more severe it is.
Short Description
MACADDR type & 00:00:00:00:00:00
Long Description
postgresql version 7.1.3, compiled with gcc 2.95.2 on solaris 2.6, running on solaris
2.8.
provisioning=> \d enduser
Table "enduser"
Attribute| Type| Modifier
-+---+
account | character varying | not null
active | boolean | not null default 't'::bool
isp_id | integer | not null
speed_plan_id | integer | not null
service_plan_id | integer | not null
node_id | integer | not null
cm_macaddr | macaddr | not null
Indices: enduser_cm_macaddr_key,
enduser_pkey
provisioning=> insert into enduser values ('2', 't', 1, 1, 1, 1, '00:00:00:00:00:00');
INSERT 20853 1
provisioning=> select account,cm_macaddr from enduser where account = '2';
account | cm_macaddr
-+
2 |
(1 row)
provisioning=> select count(*) from enduser where cm_macaddr is null;
count
---
0
(1 row)
it's not null, so shouldn't it be retrieving as '00:00:00:00:00:00'?
not that i ever expect to encounter that macaddress in the field, but
for consistency's sake...
i just tested 'ff:ff:ff:ff:ff:ff', and it works fine.
ps postgresql sends mysql running back home to mommy. you guys are my heroes.
Sample Code
No file was uploaded with this report
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] Bug #560: ODBC problem at migrating 7.0 to 7.1
Sndor, Vig ([EMAIL PROTECTED]) reports a bug with a severity of 2 The lower the number the more severe it is. Short Description ODBC problem at migrating 7.0 to 7.1 Long Description I wrote an application (in Borland CBuilder) that uses ODBC to access a DB. First I used Psql 6.5, then 7.0 without any problem. Than I have upgraded PostgreSQL and there were a lot of problems. (f.e.: sometimes a query lost aprox. half of its records) Then I made a refresh and there was everything OK. But most anoying was, that all the writing functions (Update, Delete) was impossible to execute. Error message: Unable to execute statement, becouse the table is not uniqely indexed. (So far...) I didn't changed anything in the database, and I made a backup/restore before activating the 7.1 version. I tried to configure the ODBC driver, but it was just impossible to solve this problem. Than I made a "downgrade" back to 7.0 and there was everything all rigtht. The server is an AIX 4.3.3. machine (IBM SP2) and I used PostgreSQL 7.1. downloaded from www.bull.de/pub. Sample Code I'm using standard CBuilder Database objects, without any "tricks". I can't send you any special code. No file was uploaded with this report ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #559: MACADDR type & 00:00:00:00:00:00
> MACADDR type & 00:00:00:00:00:00 > postgresql version 7.1.3, compiled with gcc 2.95.2 on solaris 2.6, running on >solaris 2.8. ... > provisioning=> select macaddr '00:00:00:00:00:00'; > it's not null, so shouldn't it be retrieving as '00:00:00:00:00:00'? > not that i ever expect to encounter that macaddress in the field, but > for consistency's sake... > i just tested 'ff:ff:ff:ff:ff:ff', and it works fine. Already fixed in the upcoming 7.2. Thanks for the report. - Thomas ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: [BUGS] Bug #559: MACADDR type & 00:00:00:00:00:00
[EMAIL PROTECTED] writes: > it's not null, so shouldn't it be retrieving as '00:00:00:00:00:00'? Yeah, due to some brain-fade on the part of the original implementor, the code went out of its way to special-case 00:00:00:00:00:00 as being represented by an empty string. This was agreed to be broken and we've changed it for 7.2. If you like you can drop the 7.2 version of the file mac.c into 7.1; see http://developer.postgresql.org/cvsweb.cgi/pgsql/src/backend/utils/adt/mac.c regards, tom lane ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] createlang
postgres@abigail ~/data $ createdb test1 Password: CREATE DATABASE postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql 'plpgsql' Password: Password: Password: Password: postgres@abigail ~/data $ createlang --list --dbname=test1 Password: Procedural languages Name | Trusted? | Compiler -+--+-- plpgsql | t| PL/pgSQL (1 row) postgres@abigail ~/data $ dropdb test1 Password: DROP DATABASE - - The createlang does not accept my password correctly. Also, should it not give a confirmation such as "CREATE" when it executes? One can see from the above output that I had to enter it 4 times. Note that it does not behave this way when I enter the incorrect password (see below). I'm on RedHat 7.1 and using the default Postgres RPM from my initial install. template1=# SELECT version() template1-# ; version - PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.96 (1 row) postgres@abigail ~/data $ cat /proc/meminfo total:used:free: shared: buffers: cached: Mem: 393175040 219648000 173527040 1470464 32092160 80633856 Swap: 2713927680 271392768 - - postgres@abigail ~/data $ createdb test1 Password: CREATE DATABASE postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql 'plpgsql' Password: psql: Password authentication failed for user 'postgres' createlang: external error postgres@abigail ~/data $ createlang --list --dbname=test1 Password: Procedural languages Name | Trusted? | Compiler --+--+-- (0 rows) postgres@abigail ~/data $ dropdb test1 Password: DROP DATABASE ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Problem with ODBC Driver Version 7.1.9, DB Version 7.1.3
Severity: Major
Short description: Problem with ODBC Driver Version 7.1.9, DB Version 7.1.3
Long description:
created table umsatz:
fakt32=# \d umsatz
Table "umsatz"
Attribute | Type | Modifier
+---+
inr| integer | not null default
nextval('"umsatz_inr_seq"'::text)
kdnr | bigint| default 0
jahr | integer | default 0
menge | real | default 0
netto | real | default 0
nettostamm | real | default 0
kz | character varying(2) |
kolltext | character varying(30) |
agtext | character varying(30) |
rabproz| real | default 0
Indices: umsatz_kdnr_key,
umsatz_pkey
as you can see: field "kdnr" is defined as bigint;
using MsAccess as frontend; connecting tables via ODBC (Driver Version 7.1.9);
field "kdnr" is shown as type text length(19)
Example code:
"Select * from umsatz where kdnr = 2" gives Error-Message: Data Type
mismatch in criteria expression.
Please help!
Best regards
Wolfgang
-
Wolfgang Fürtbauer [EMAIL PROTECTED]
Steinbichlstrasse 58d 07612/77620
A-4812 Pinsdorf
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] arrays broken in 7.1.3? also, support for embedded tables?
Hi, I'm running 7.1.3 on a redhat linux system, using the rpm packages from
the postgresql site:
[nova@naomi scripts]$ rpm -qa|grep postgresql
postgresql-libs-7.1.3-0.onms.5
postgresql-server-7.1.3-0.onms.5
postgresql-python-7.1.3-0.onms.5
postgresql-7.1.3-0.onms.5
postgresql-contrib-7.1.3-0.onms.5
postgresql-docs-7.1.3-0.onms.5
I've been having some problems with getting arrays to work (either I'm doing
something stupid, or they seem to be broken).
Here's what I try:
allshotup=# CREATE TABLE foo (bla0 text, bla1 varchar(20)[], bla2
char(20)[], bla3 text[]);
CREATE
allshotup=# INSERT INTO foo (bla0) VALUES ('test');
INSERT 19408 1
allshotup=# UPDATE foo SET bla1[1] = 'bla1', bla2[1] = 'bla2', bla3[1] =
'bla3' WHERE bla0='test';
UPDATE 1
allshotup=# SELECT * FROM foo;
bla0 | bla1 | bla2 | bla3
--+--+--+--
test | | |
(1 row)
allshotup=# SELECT bla1[1] FROM foo WHERE bla0='test';
bla1
--
(1 row)
-
etc
Am I doing something wrong? (Note that I don't think this matters, but I
have installed the array-related contrib stuff that defines the operators
like *=, etc)
Lastly, I was wondering if anyone knew if support for embedding tables
exists? I've heard that at one point pgsql had this, but the object
relational stuff kind of got out of date and this got deprecated.
Thanks.
Robby Dermody
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] ehm...
well, i will be a little verbose, but i am afraid this could be a big bug in postgresql, so... i've made a script in python that, by psycopg module, put freecddb archive in a relational db. so, it does a few select and a lot of insert for each file of freecddb (something like 500.000 files). now, the process is slower (most of the time is spent reading small file, parsing and generating the right query), so i have try it just 8 times, and now i need to know if i am wrong or if is it a real postgresql problem (having see the problem of duplicated key, and so on). well, just to make this a little bit more a bug report: os: linux 2.4.18pre1 (also tried with 2.4.17) distribution: debian unstable gcc: gcc version 3.0.3 (also tried with 3.0.2) python: 2.1 psycopg: http://packages.debian.org/unstable/non-us/python2.1-psycopg.html postgresql: different cvs version in last 8 days now, what happen is simple: i run my script and after a lot of insert (the error in the bottom appears after 76242 file parsed), if i run vacuumdb i've got different error. i.e.: vacuumdb -a -v -f -z NOTICE: Analyzing author FATAL 2: open of /home/postgres/db/pg_clog/ failed: No such file or directo ry server closed the connection unexpectedly This probably means the server terminated abnormally before or while processing the request. connection to server was lost vacuumdb: vacuum freecddb failed i've got errors like this using vacuum with and without '-f', with db working and with db doing nothing else than vacuum. sometimes i've got errors of duplicated key (already know problem), but that time i didn't 'cut & paste' the error believing it was my fault by some mistake in my schema. now, i can investigate deeply, but i need your opinion if it is something to do or not. as i said, it takes longer to reproduce this (and maybe i'm doing something wrong). thanks a lot for your work, andrea n.b.: well, if i try on the same postgres to run other db i've got no problem, but they are a lot smaller and have a few read access and less write access per day (3-4 insert, without foreing keys, and one hundred select). ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
[BUGS] pltclU
Hello, I am a postgres novice. I was trying to install pltclu for running some tcl function to enable mailing from postgres. But I am not able to find the required shared object file (.so extension) for installing that language. I am able to install the language pltcl using the file pltcl.so. How should I install this untrusted version of pltcl ??? Regards, Jayaraj O Bangalore ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
[BUGS] MACADDR type & 00:00:00:00:00:00
postgresql version 7.1.3, compiled with gcc 2.95.2 on solaris 2.6, running
on solaris 2.8.
provisioning=> \d enduser
Table "enduser"
Attribute| Type| Modifier
-+---+
account | character varying | not null
active | boolean | not null default 't'::bool
isp_id | integer | not null
speed_plan_id | integer | not null
service_plan_id | integer | not null
node_id | integer | not null
cm_macaddr | macaddr | not null
Indices: enduser_cm_macaddr_key,
enduser_pkey
provisioning=> insert into enduser values ('2', 't', 1, 1, 1, 1, '00:00:00:00:00:00');
INSERT 20853 1
provisioning=> select account,cm_macaddr from enduser where account = '2';
account | cm_macaddr
-+
2 |
(1 row)
provisioning=> select count(*) from enduser where cm_macaddr is null;
count
---
0
(1 row)
it's not null, so shouldn't it be retrieving as '00:00:00:00:00:00'?
not that i ever expect to encounter that macaddress in the field, but
for consistency's sake...
i just tested 'ff:ff:ff:ff:ff:ff', and it works fine.
ps postgresql sends mysql running back home to mommy. you guys are my heroes.
--
[EMAIL PROTECTED] (michael handler) washington, dc
---(end of broadcast)---
TIP 6: Have you searched our list archives?
http://archives.postgresql.org
[BUGS] LIBPQ: program crashed during executing query
Hi! My C program executes a pretty complex query (of length about 600 chars, with subqueries, etc.). When I run it (on Linux), it crashes with "Segmentation fault (core dumped)". I'm sure that the program crashes on this specific PQexec command. Is there a length limit for queries in PQexec, or is there any other reason for it? The query is attached. Thanks in advance, Alex P.S. The query is: SELECT s1.GivingCode FROM Scored s1, Scored s2 WHERE s1.Score >= 8 AND s2.Score >= 8 AND s1.Year = s2.Year AND s1.GivingCode = s2.ReceivingCode AND s1.ReceivingCode = s2.GivingCode AND s1.GivingCode NOT IN (SELECT Code FROM Friends) AND s1.ReceivingCode IN (SELECT Code FROM Friends) AND NOT EXISTS (SELECT * FROM Represented re1, Represented re2, Scored sc WHERE re1.Year = re2.Year AND re1.Year = sc.Year AND re1.Code = s1.GivingCode AND re2.Code = s1.ReceivingCode AND ((sc.GivingCode = s1.ReceivingCode AND sc.ReceivingCode = s1.GivingCode AND sc.Score < 8) OR (sc.GivingCode = s1.GivingCode AND sc.ReceivingCode = s1.ReceivingCode AND sc.Score < 8))) ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] ECPG bug in --help
On Fri, Jan 04, 2002 at 01:52:32PM -0500, Bruce Momjian wrote: > Looking at this I also found an ecpg TODO list in the docs: > > http://candle.pha.pa.us/main/writings/pgsql/sgml/ecpg-develop.html > > Seems that TODO section should be removed. Some items are done, others > are on the main TODO list. That's correct. I did not fix the docs for quite some time. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] ECPG bug in --help
On Fri, Jan 04, 2002 at 04:02:14PM +, Lee Kindness wrote: > Michael, hope you've had a good Christmas & all the best for the New > Year... Sure. Thanks. > When you run 'ecpg --help' you get the following: > > -t turn on autocommit of transactions > > amongst the other options... Shouldn't this be OFF as per the > documentation? No, this is correct. However, there are some problems in the wording. autocommit means "use the default transactions from PGSQL" while auto-transaction mode means to "start a new transaction after each commit". The latter is the way Oracle handles this, you just have to issue commits but no begin trans. The first of course is the very same as working with pgsql. This needs some clearer wording urgently. I haven't checked Bruce changes so far. Michael -- Michael Meskes [EMAIL PROTECTED] Go SF 49ers! Go Rhein Fire! Use Debian GNU/Linux! Use PostgreSQL! ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] LIBPQ: program crashed during executing query
Please, ignore my question. The problem was that I did PQclear(res) before calling to PQgetvalue(res,...) Anyway, it should not crush (IMHO). Alex "Alex Glikson" <[EMAIL PROTECTED]> wrote in message a1jjj5$tas$[EMAIL PROTECTED]">news:a1jjj5$tas$[EMAIL PROTECTED]... > Hi! > > My C program executes a pretty complex query (of length about 600 chars, > with subqueries, etc.). > When I run it (on Linux), it crashes with "Segmentation fault (core > dumped)". > I'm sure that the program crashes on this specific PQexec command. > > Is there a length limit for queries in PQexec, or is there any other reason > for it? > The query is attached. > > Thanks in advance, > > Alex > > P.S. The query is: > SELECT s1.GivingCode FROM Scored s1, Scored s2 > WHERE s1.Score >= 8 AND s2.Score >= 8 AND s1.Year = s2.Year AND >s1.GivingCode = s2.ReceivingCode AND s1.ReceivingCode = s2.GivingCode AND >s1.GivingCode NOT IN (SELECT Code FROM Friends) AND >s1.ReceivingCode IN (SELECT Code FROM Friends) AND >NOT EXISTS (SELECT * FROM Represented re1, Represented re2, Scored sc > WHERE > re1.Year = re2.Year AND re1.Year = sc.Year AND re1.Code = s1.GivingCode > AND > re2.Code = s1.ReceivingCode AND > ((sc.GivingCode = s1.ReceivingCode AND sc.ReceivingCode = s1.GivingCode > AND sc.Score < 8) OR > (sc.GivingCode = s1.GivingCode AND sc.ReceivingCode = s1.ReceivingCode > AND sc.Score < 8))) > > > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
[BUGS] Bad integer
I'm getting "Bad integer 4020239173" error. From what I found on the Web it seems to be a Postgres bug, not specific to any programming language. I've found PHP and Java guys complaining about it (I'm using JDBC). However, I failed to find resolution of this problem. Can you suggest something? -- Best regards, Dmitry mailto:[EMAIL PROTECTED] ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] createlang
I have noticed that some of the command line tools do not work nicely when the local auth is not set to trust, but trust is dangerous. Have you tried creating the language from psql rather than from the command line? [EMAIL PROTECTED] wrote: >postgres@abigail ~/data $ createdb test1 >Password: >CREATE DATABASE > >postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql >'plpgsql' >Password: Password: Password: >Password: > >postgres@abigail ~/data $ createlang --list --dbname=test1 >Password: > Procedural languages > Name | Trusted? | Compiler >-+--+-- > plpgsql | t| PL/pgSQL >(1 row) > > >postgres@abigail ~/data $ dropdb test1 >Password: >DROP DATABASE > > > >- > >- > >The createlang does not accept my password correctly. Also, should it not >give a confirmation such as "CREATE" when it executes? One can see from the >above output that I had to enter it 4 times. Note that it does not behave >this way when I enter the incorrect password (see below). > >I'm on RedHat 7.1 and using the default Postgres RPM from my initial >install. > >template1=# SELECT version() >template1-# ; > version >- > PostgreSQL 7.0.3 on i686-pc-linux-gnu, compiled by gcc 2.96 >(1 row) > >postgres@abigail ~/data $ cat /proc/meminfo >total:used:free: shared: buffers: cached: >Mem: 393175040 219648000 173527040 1470464 32092160 80633856 >Swap: 2713927680 271392768 > > >- > >- > > >postgres@abigail ~/data $ createdb test1 >Password: >CREATE DATABASE > >postgres@abigail ~/data $ createlang --dbname=test1 --pglib=/usr/lib/pgsql >'plpgsql' >Password: psql: Password authentication failed for user 'postgres' >createlang: external error > >postgres@abigail ~/data $ createlang --list --dbname=test1 >Password: >Procedural languages > Name | Trusted? | Compiler >--+--+-- >(0 rows) > > >postgres@abigail ~/data $ dropdb test1 >Password: >DROP DATABASE > > > > >---(end of broadcast)--- >TIP 6: Have you searched our list archives? > >http://archives.postgresql.org > ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: [BUGS] ehm...
andrea gelmini <[EMAIL PROTECTED]> writes: > vacuumdb -a -v -f -z > NOTICE: Analyzing author > FATAL 2: open of /home/postgres/db/pg_clog/ failed: No such file or directo > ry > server closed the connection unexpectedly > This probably means the server terminated abnormally > before or while processing the request. > connection to server was lost > vacuumdb: vacuum freecddb failed > i've got errors like this using vacuum with and without '-f', with db > working and with db doing nothing else than vacuum. > sometimes i've got errors of duplicated key (already know problem), but > that time i didn't 'cut & paste' the error believing it was my fault by > some mistake in my schema. > now, i can investigate deeply, but i need your opinion if it is something > to do or not. as i said, it takes longer to reproduce this (and maybe i'm > doing something wrong). Yup, it looks like a bug to me. Apparently a CLOG segment has been recycled too soon. We just found a bug of that ilk in sequence processing, but VACUUM doesn't touch sequences, so apparently you have a different bug. Please submit details. Since CLOG segments normally hold a million transactions each, it'll necessarily take a long time to reproduce any problem of this kind. If you don't mind doing an initdb, you could reduce the CLOG segment size to make it easier to try to reproduce the problem. In src/backend/access/transam/clog.c change #define CLOG_XACTS_PER_SEGMENT 0x10 to 0x1 (I think that's about as small as you can make it without breaking anything). That gives you a shot at a problem every 64K transactions. regards, tom lane ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
[BUGS] postgresql 7.2b4 bug?
my database create -E UNICODE
can't run
timestamp(date '2000-12-25')
error message>> parse error at or near "date"
lpad('hi',4,'??') >> not return '??hi'
rpad('hi',4,'x') >> return error string
--
---(end of broadcast)---
TIP 5: Have you checked our extensive FAQ?
http://www.postgresql.org/users-lounge/docs/faq.html
Re: [BUGS] Bad integer
Dmitry Macsema <[EMAIL PROTECTED]> writes:
> I'm getting "Bad integer 4020239173" error. From what I found on the
> Web it seems to be a Postgres bug, not specific to any programming
> language.
First I've heard of it. You're going to have to provide a lot more
information if you want us to believe it's a Postgres problem.
The only occurrence of the string "bad integer" in current postgres
sources is
src/interfaces/jdbc/org/postgresql/errors.properties: postgresql.res.badint:Bad
Integer {0}
which appears to be an exception thrown only by toInt(). Complaining
because someone tried to coerce an oversize value to integer is not
obviously a bug...
regards, tom lane
---(end of broadcast)---
TIP 2: you can get off all lists at once with the unregister command
(send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: [BUGS] ehm...
andrea gelmini <[EMAIL PROTECTED]> writes: > On ven, gen 11, 2002 at 01:56:12 -0500, Tom Lane wrote: >> Yup, it looks like a bug to me. Apparently a CLOG segment has been >> recycled too soon. We just found a bug of that ilk in sequence >> processing, but VACUUM doesn't touch sequences, so apparently you have >> a different bug. Please submit details. > yes, i will retry tonight. > what kind of info do you want? > by the way i can give you script and the rest of things you need (and it will be very > easily for you to reproduce the problem... the script is very simple, and > schema is nothing more than a few tables). Yes, I would like a copy of your script. I just found and fixed a problem that could lead to this kind of failure (reference to an already-deleted CLOG entry). However, I'm not sure that the problem I fixed could affect VACUUM itself. Please update from cvs (make sure you get src/backend/utils/time/tqual.c v 1.46) and then see if you still see the problem. If you do, a backtrace from the point where elog() is called would be really helpful. regards, tom lane ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: [BUGS] Bug #560: ODBC problem at migrating 7.0 to 7.1
> > Sndor, Vig ([EMAIL PROTECTED]) reports a bug with a severity of 2 > The lower the number the more severe it is. > > Short Description > ODBC problem at migrating 7.0 to 7.1 > > Long Description > I wrote an application (in Borland CBuilder) that uses ODBC to access > a DB. First I used Psql 6.5, then 7.0 without any problem. Than I > have upgraded PostgreSQL and there were a lot of problems. (f.e.: > sometimes a query lost aprox. half of its records) Then I made a > refresh and there was everything OK. But most anoying was, that all > the writing functions (Update, Delete) was impossible to execute. > Error message: Unable to execute statement, becouse the table is not > uniqely indexed. (So far...) I didn't changed anything in the > database, and I made a backup/restore before activating the 7.1 > version. What version of psqlodbc driver are you using ? Could you turn on the Mylog debug output and send me the result ? regards, Hiroshi Inoue ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
