First of all, you really really really want to use place holders for starters, to prevent SQL injection (also see a column on this by merlyn).

And to be honest, I think that'd solve your quoting problem too (for I assume the lack of quotes around the $testTitle is giving your DB problems)

(besides the commit answer, given by aquarium, of course).

cheers mate will give that a try

$db->delete('music', { title => param('title') });
[download]

A really nice thing about SQL::Abstract and, thus, DBIx::Simple is that it takes care of the special case where the value is undef, for a field value of NULL, too. Just using placeholders wouldn't do, as the SQL query

DELETE FROM music WHERE title = NULL
[download]

Be aware that directly using the results of the param function as key/value pairs for a hash opens up an interesting attack vector if you have more than one key/value pair. Assume the above code and the following query, which doubles the title parameter to whack the key/value pairing off by one, turning all subsequent keys into values and all subsequent values into keys:

?title=foo;title=user;bar=
[download]

This would send off the following query instead:

$db->delete('music', { title => 'foo', user => undef });
[download]

In this specific case, the attack isn't effective obviously, as you can still only add more restrictions on what rows to delete, instead of widening the query. If the attacker can guess one of the parameters that need to be overridden, this still can be an effective attack:

$db->insert('users', { is_admin => 0, user => param('username') });
[download]

Here, the attacker can easily overwrite admin to any value they want by supplying an appropriately formatted query:

?user=corion;user=is_admin;user=1
[download]

So, I think that one should never use the results of param() directly in another list that will get passed on without further scrunity. Note that no parameter validation that validates a single parameter will protect you against this vector.

OK... So how about this?

$db->delete('music', { title => scalar param('title') });
[download]

I was curious about this, so I ran a quick test and was unable to duplicate your findings (CGI.pm version 3.05). In my output, the keys and values appear as I would expect. Can you please explain how you came to your conclusion? Here's my code:

#!/usr/bin/perl

use strict;
use warnings;

use CGI;

my $cgi = CGI->new();

use Data::Dumper::Simple;
print Dumper($cgi);
print scalar $cgi->param('title');
print $/;

__END__

> ./tmp.pl title=foo\;title=user\;bar=
$cgi = bless( {
                '.parameters' => [
                                   'title',
                                   'bar'
                                 ],
                'bar' => [
                           ''
                         ],
                '.charset' => 'ISO-8859-1',
                '.fieldnames' => {},
                'title' => [
                             'foo',
                             'user'
                           ],
                'escape' => 1
              }, 'CGI' );
foo
[download]

Thanks!

---
It's all fine and dandy until someone has to look at the code.

in some sense I just conclude the previous answers: The perlish part
1. Don't use user inputs directly to modify a database Use tainted variables, arrange the input intelligently.
The Database part:
2. It seems, that you use one large table for your project. However, you should really do some normalization. For example, create tables for the Artists, CDs, Titles separately. At least you should try to separate the static part of your database from the changing part, or slowly changing parts from fast changing parts. For example, create a table for the users (it is relatively static) and a table for the comments or deleted titles (relatively dynamic).
3. DELETE is on every serious RDBMS an operation that requires a COMMIT (sometimes this is done automatically) because it is an operation that can leave the database in an inconsistent state. May be, it is required here.
4. If DELETE is done frequently, use prepared statements.
These are some ideas for the moment. I hope these are useful for the further design.