Hughes, Andrew [[EMAIL PROTECTED]] wrote:
> Thanks for all of the feedback. I realize that using the eval{} statement
> is probably the way to go. However, as I am new to this, I don't quite "get
> it" yet. Since this is going to be on a relatively low-traffic intranet
> site behind a firewall, I used a MySQL query in a subroutine before the
> insert subroutine is called. If it finds the submitted e-mail in the
> database, it prints a nice error message that I created to the browser and
> the script stops.
That is ok, but not really. I did this same thing when I wrote
my first database application, and people on this list corrected
me - it's best to learn the right way to do this the 1st time. As
Thomas Lowery(I think? Time of Update, Time of Use, or something
like that) pointed out earlier in this thread, and Steve Haslam
below, you should *NOT* depend on a query before your insert as
the definitive check to see if your insert will produce a duplicate.
***Again, the right way to do this is to:
* create a "unique" key such that attempting to insert a
duplicate will fail in the database
* with your dbi code, attempt your insert - and surround your
insert with an eval so you can trap the error - the error
message, containing some "duplicate key" string, will end
up in special variable $@.
* After your eval, test the contents of the $@ variable - if
there is something in it, then the eval failed - go on to
test the contents for whatever "duplicate" key message your
database will produce - if the error string($@) contains
that duplicate key message, then the eval failed because
you tried to insert a duplicate.
Please re-read the message from Steve Haslam(below) and Thomas
Lowery(I hope I have this right).
Also, read the DBI perldocs by doing
perldoc DBI
at a command prompt. Once there, do a search(using the forward
slash "/") for "eval" - you'll come to a section describing it's
proper use - the section is titled "Transactions".
Here is a piece of that "Transactions" section, with some code
I added to help you check for the duplicate key situation - this
is pretty much exactly the same as the code Steve Haslam sent
below. This code assumes that your database produces a message
which contains the string "duplicate key" when you try to insert
a row which violates the unique key you created:
$dbh‐>{AutoCommit} = 0; # enable transactions, if possible
$dbh‐>{RaiseError} = 1;
eval {
foo(...) # do lots of work here
bar(...) # including inserts
baz(...) # and updates
$dbh‐>commit; # commit the changes if we get this far
};
if ($@) {
### This next if created by HM to illustrate dup key
### check.
if ($@ =~ /duplicate key/) {
### the error was caused by a duplicate key
### violation.
}
else }
### There was an error in the eval, but it was
### *NOT* caused by a duplicate key.
}
warn "Transaction aborted because $@";
$dbh‐>rollback; # undo the incomplete changes
# add other application on‐error‐clean‐up code here
}
What I've done in the past was have this "INSERT" code in a
subroutine - if the insert works fine, have the subroutine
return "OK" - if it fails because of a "duplicate", have the
subroutine return "DUP" - if it fails for any other reason,
have the subroutine return "ERROR". The code that calls the
subroutine would check the return code:
$rc = my_insert();
if ($rc ne "OK") {
if ($rc eq "DUP") {
### display a message telling user there is a dup
}
else {
### This is a serious error - do something appropriate
### here
}
This is just one way to do it, but hopefully it gives you an
idea of how the dup checking might be done.
HTH.
--
Hardy Merrill
Senior Software Engineer
Red Hat, Inc.
>
> Thanks for all of your feedback. I actually bought Perl DBI yesterday, so
> hopefully, I will soon grasp a better understanding of the DBI module.
>
> Thanks,
> Andrew
>
> -----Original Message-----
> From: Steve Haslam [mailto:[EMAIL PROTECTED]]
> Sent: Monday, January 20, 2003 12:31 PM
> To: 'Hughes, Andrew'; '[EMAIL PROTECTED]'
> Subject: RE: Error Handling
>
>
> > entered into the database. With this code, I recieve the Carp error in
> the
> > browser. When I turn off Carp, the script acts as if the entry was added
> > (no error displayed), but the record is not entered. Can anyone offer
> > suggestions on how to make decisions based on a DBI error message ?
>
> wrap your $dbh->do() in an eval block:
>
> eval {
> $dbh->do( ... insert statement ... );
> };
> if ($@ =~ /constraint violation/) # or whatever the error message is
> {
> return &duplicate_email();
> }
> elsif ($@) # some other error occurred
> {
> die $@;
> }
> # insert succeeded...
>
>
> Please note that:
>
> 1. This e-mail may constitute privileged information. If you are not the
> intended recipient, you have received this confidential email and any
> attachments transmitted with it in error and you must not disclose, copy,
> circulate or in any other way use or rely on this information.
> 2. E-mails to and from the company are monitored for operational reasons and
> in accordance with lawful business practices.
> 3. The contents of this email are those of the individual and do not
> necessarily represent the views of the company.
> 4. The company does not conclude contracts by email and all negotiations are
> subject to contract.
> 5. The company accepts no responsibility once an e-mail and any attachments
> is sent.
>
> http://www.activis.com
>
>
>
>
> This annotation was added by the e-scan service.
> http://www.activis.com
> ----------------------------------------------------------------------------
> ------
> This message has been checked for all known viruses by e:)scan.
> For further information please contact [EMAIL PROTECTED]
