hesco has asked for the wisdom of the Perl Monks concerning the following question:
is throwing this error:$sth_mlg_addr_duplicate_check->execute($fields[17],$fields[18],$fields +[19],$fields[20],$fields[21],$fields[22],$fields[23]) or warn "While checking for duplicate mailing address $fields[17 +]; $fields[19] $fields[20]: " . $dbh->errstr; ($mlg_addr_id) = $sth_mlg_addr_duplicate_check->fetchrow_array(); my $mlg_id; if(!defined($mlg_addr_id) && length($fields[20]) == 2){ $sth_insert_mlg_addr->execute($fields[17],$fields[18],$fields[19 +],$fields[20],$fields[21],$fields[22],$fields[23]) or warn "While inserting new mailing address |$fields[17]|; |$ +fields[19]| |$fields[20]|, with id |$mlg_addr_id|: " . $dbh->errstr; $sth_mlg_addr_duplicate_check->execute($fields[17],$fields[18],$ +fields[19],$fields[20],$fields[21],$fields[22],$fields[23]) or warn "While checking for duplicate mailing address |$fields +[17]|; |$fields[19]| |$fields[20]|: " . $dbh->errstr; ($mlg_addr_id) = $sth_mlg_addr_duplicate_check->fetchrow_array() +; $mlg_id = $mlg_addr_id; } else { $mlg_id = $mlg_addr_id; # print STDERR "\$mlg_addr_id is already defined as $mlg_addr_id +.\n"; }
even though, after having done so, and from a psql prompt I'm getting:Use of uninitialized value in concatenation (.) or string at parse_vot +er_list.pl line 251, <$fh> line 3483. While inserting new mailing address |xxxx RUE LOUIS PHILLIPPE|; |MARRE +RO| |LA|, with id ||: ERROR: duplicate key violates unique constrain +t "mlg_addr_uniq_key" While checking for duplicate mailing address |xxxx RUE LOUIS PHILLIPPE +|; |MARRERO| |LA|: ERROR: current transaction is aborted, commands i +gnored until end of transaction block While checking for duplicate residential address: ERROR: current tran +saction is aborted, commands ignored until end of transaction block Issuing rollback() for database handle being DESTROY'd without explici +t disconnect().
For the gruesome details:=# SELECT * FROM mlg_addr WHERE address1 LIKE '%RUE LOUIS PHILLIPPE' A +ND city = 'MARRERO' AND state = 'LA'; mlg_addr_id | address1 | address2 | city | state | zipcode5 | zipcode +4 | country -------------+----------+----------+------+-------+----------+-------- +--+--------- (0 rows)
and:my $mlg_addr_duplicate_check =<<EOQ; SELECT mlg_addr_id FROM mlg_addr WHERE address1 = ? AND address2 = ? AND city = ? AND state = ? AND zipcode5 = ? AND zipcode4 = ? AND country = ? EOQ my $sth_mlg_addr_duplicate_check = $dbh->prepare($mlg_addr_duplicate_c +heck) or die $dbh->errstr; my $insert_mlg_addr =<<EOQ; INSERT INTO mlg_addr (address1,address2,city,state,zipcode5,zipcode4,country) VALUES(?,?,?,?,?,?,?); EOQ my $sth_insert_mlg_addr = $dbh->prepare($insert_mlg_addr) or die $dbh- +>errstr;
The @fields array includes the following fields:=# \d mlg_addr Table "public.mlg_addr" Column | Type | Modifie +rs -------------+-----------------------+-------------------------------- +--------------------------- mlg_addr_id | integer | not null default nextval(('mlg_ +addr_id'::text)::regclass) address1 | character varying(65) | address2 | character varying(65) | city | character varying(40) | state | character varying(2) | zipcode5 | character varying(5) | zipcode4 | character varying(4) | country | character varying(45) | Indexes: "mlg_addr_id_key" UNIQUE, btree (mlg_addr_id) "mlg_addr_uniq_key" UNIQUE, btree (country, zipcode5, zipcode4, ad +dress1, address2)
address1 = $fields[17] address2 = $fields[18] city = $fields[19] state = $fields[20] zipcode5 = $fields[21] zipcode4 = $fields[22] country = $fields[13]
Why would this query fail when there obviously is no duplicate in that table?
-- Hugh
UPDATE:
In response to moritz's questions about the details on the schema and the queries and variables, I've added some of the gruesome details behind the readmore tags.
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: duplicate key check isn't, why not?
by moritz (Cardinal) on Nov 23, 2008 at 15:52 UTC | |
|
Re: duplicate key check isn't, why not?
by oeuftete (Monk) on Nov 23, 2008 at 16:01 UTC | |
by hesco (Deacon) on Nov 23, 2008 at 16:22 UTC | |
|
Re: duplicate key check isn't, why not?
by oeuftete (Monk) on Nov 23, 2008 at 16:22 UTC | |
|
Re: duplicate key check isn't, why not?
by graff (Chancellor) on Nov 23, 2008 at 20:37 UTC | |
|
Re: duplicate key check isn't, why not?
by eric256 (Parson) on Nov 25, 2008 at 17:33 UTC |