Код: Выделить всё
if ( $code eq 'reject:' ){
my %arr = split /[\[\]<>]/, $message; #Разбивка по любому из 4-х символов: [ ] < >
foreach my $i (keys %arr)
{
print "$i"; #вывод ключей хеша
print "$arr{$i}"; #вывод значений хеша
#теперь как-то надо данные из хеша занести в БД
$dbh->do("INSERT INTO `reject` (`ip`,`mailfrom`,`rcptto`) VALUES(?,?,?), undef, $arr{$i} );
}
print "\n";
}
}
ну если так как вы задумали то так...
т.е. каждый ключ нужно вставить сюда
$dbh->do("INSERT INTO `reject` (`ip`,`mailfrom`,`rcptto`) VALUES(?,?,?), undef, $arr{$i} );
можно вставить и одним запросом:
http://search.cpan.org/~timb/DBI-1.609/ ... aram_array
bind_param_array
$rc = $sth->bind_param_array($p_num, $array_ref_or_value)
$rc = $sth->bind_param_array($p_num, $array_ref_or_value, \%attr)
$rc = $sth->bind_param_array($p_num, $array_ref_or_value, $bind_type)
The bind_param_array method is used to bind an array of values to a placeholder embedded in the prepared statement which is to be executed with "execute_array". For example:
$dbh->{RaiseError} = 1; # save having to check each method call
$sth = $dbh->prepare("INSERT INTO staff (first_name, last_name, dept) VALUES(?, ?, ?)");
$sth->bind_param_array(1, [ 'John', 'Mary', 'Tim' ]);
$sth->bind_param_array(2, [ 'Booth', 'Todd', 'Robinson' ]);
$sth->bind_param_array(3, "SALES"); # scalar will be reused for each row
$sth->execute_array( { ArrayTupleStatus => \my @tuple_status } );
The %attr ($bind_type) argument is the same as defined for "bind_param". Refer to "bind_param" for general details on using placeholders.
(Note that bind_param_array() can not be used to expand a placeholder into a list of values for a statement like "SELECT foo WHERE bar IN (?)". A placeholder can only ever represent one value per execution.)
Scalar values, including undef, may also be bound by bind_param_array. In which case the same value will be used for each "execute" call. Driver-specific implementations may behave differently, e.g., when binding to a stored procedure call, some databases may permit mixing scalars and arrays as arguments.
The default implementation provided by DBI (for drivers that have not implemented array binding) is to iteratively call "execute" for each parameter tuple provided in the bound arrays. Drivers may provide more optimized implementations using whatever bulk operation support the database API provides. The default driver behaviour should match the default DBI behaviour, but always consult your driver documentation as there may be driver specific issues to consider.
Note that the default implementation currently only supports non-data returning statements (INSERT, UPDATE, but not SELECT). Also, bind_param_array and "bind_param" cannot be mixed in the same statement execution, and bind_param_array must be used with "execute_array"; using bind_param_array will have no effect for "execute".
The bind_param_array method was added in DBI 1.22.
http://search.cpan.org/~timb/DBI-1.609/ ... cute_array
execute_array
$tuples = $sth->execute_array(\%attr) or die $sth->errstr;
$tuples = $sth->execute_array(\%attr, @bind_values) or die $sth->errstr;
($tuples, $rows) = $sth->execute_array(\%attr) or die $sth->errstr;
($tuples, $rows) = $sth->execute_array(\%attr, @bind_values) or die $sth->errstr;
Execute the prepared statement once for each parameter tuple (group of values) provided either in the @bind_values, or by prior calls to "bind_param_array", or via a reference passed in \%attr.
When called in scalar context the execute_array() method returns the number of tuples executed, or undef if an error occurred. Like execute(), a successful execute_array() always returns true regardless of the number of tuples executed, even if it's zero. If there were any errors the ArrayTupleStatus array can be used to discover which tuples failed and with what errors.
When called in list context the execute_array() method returns two scalars; $tuples is the same as calling execute_array() in scalar context and $rows is the sum of the number of rows affected for each tuple, if available or -1 if the driver cannot determine this. If you are doing an update operation the returned rows affected may not be what you expect if, for instance, one or more of the tuples affected the same row multiple times. Some drivers may not yet support list context, in which case $rows will be undef, or may not be able to provide the number of rows affected when performing this batch operation, in which case $rows will be -1.
Bind values for the tuples to be executed may be supplied row-wise by an ArrayTupleFetch attribute, or else column-wise in the @bind_values argument, or else column-wise by prior calls to "bind_param_array".
Where column-wise binding is used (via the @bind_values argument or calls to bind_param_array()) the maximum number of elements in any one of the bound value arrays determines the number of tuples executed. Placeholders with fewer values in their parameter arrays are treated as if padded with undef (NULL) values.
If a scalar value is bound, instead of an array reference, it is treated as a variable length array with all elements having the same value. It's does not influence the number of tuples executed, so if all bound arrays have zero elements then zero tuples will be executed. If all bound values are scalars then one tuple will be executed, making execute_array() act just like execute().
The ArrayTupleFetch attribute can be used to specify a reference to a subroutine that will be called to provide the bind values for each tuple execution. The subroutine should return an reference to an array which contains the appropriate number of bind values, or return an undef if there is no more data to execute.
As a convenience, the ArrayTupleFetch attribute can also be used to specify a statement handle. In which case the fetchrow_arrayref() method will be called on the given statement handle in order to provide the bind values for each tuple execution.
The values specified via bind_param_array() or the @bind_values parameter may be either scalars, or arrayrefs. If any @bind_values are given, then execute_array will effectively call "bind_param_array" for each value before executing the statement. Values bound in this way are usually treated as SQL_VARCHAR types unless the driver can determine the correct type (which is rare), or unless bind_param, bind_param_inout, bind_param_array, or bind_param_inout_array has already been used to specify the type. See "bind_param_array" for details.
The ArrayTupleStatus attribute can be used to specify a reference to an array which will receive the execute status of each executed parameter tuple. Note the ArrayTupleStatus attribute was mandatory until DBI 1.38.
For tuples which are successfully executed, the element at the same ordinal position in the status array is the resulting rowcount. If the execution of a tuple causes an error, then the corresponding status array element will be set to a reference to an array containing the error code and error string set by the failed execution.
If any tuple execution returns an error, execute_array will return undef. In that case, the application should inspect the status array to determine which parameter tuples failed. Some databases may not continue executing tuples beyond the first failure. In this case the status array will either hold fewer elements, or the elements beyond the failure will be undef.
If all parameter tuples are successfully executed, execute_array returns the number tuples executed. If no tuples were executed, then execute_array() returns "0E0", just like execute() does, which Perl will treat as 0 but will regard as true.
For example:
$sth = $dbh->prepare("INSERT INTO staff (first_name, last_name) VALUES (?, ?)");
my $tuples = $sth->execute_array(
{ ArrayTupleStatus => \my @tuple_status },
\@first_names,
\@last_names,
);
if ($tuples) {
print "Successfully inserted $tuples records\n";
}
else {
for my $tuple (0..@last_names-1) {
my $status = $tuple_status[$tuple];
$status = [0, "Skipped"] unless defined $status;
next unless ref $status;
printf "Failed to insert (%s, %s): %s\n",
$first_names[$tuple], $last_names[$tuple], $status->[1];
}
}
Support for data returning statements such as SELECT is driver-specific and subject to change. At present, the default implementation provided by DBI only supports non-data returning statements.
Transaction semantics when using array binding are driver and database specific. If AutoCommit is on, the default DBI implementation will cause each parameter tuple to be individually committed (or rolled back in the event of an error). If AutoCommit is off, the application is responsible for explicitly committing the entire set of bound parameter tuples. Note that different drivers and databases may have different behaviours when some parameter tuples cause failures. In some cases, the driver or database may automatically rollback the effect of all prior parameter tuples that succeeded in the transaction; other drivers or databases may retain the effect of prior successfully executed parameter tuples. Be sure to check your driver and database for its specific behaviour.
Note that, in general, performance will usually be better with AutoCommit turned off, and using explicit commit after each execute_array call.
The execute_array method was added in DBI 1.22, and ArrayTupleFetch was added in 1.36.
