I'm sorry I don't currently have access to a database to test this against, but I believe this should work:

my $sth = $dbh->prepare(q~
    select
        smt.uniqueid, smt.creationtime, att.name, att.val, gsm.msisdn
    from
        dagenericsmt smt, dagenericsmtattribute att, dagsmproduct gsm
    where smt.uniqueid = att.genericsmt_uniqueid
        and smt.product_uniqueid = gsm.uniqueid
        and smt.smtstatus=2
        and smt.smtcommand=3
        and att.name in ('GSM/Cur/IMSI','GSM/Rpl/IMSI')
        and smt.acktime is null order by smt.uniqueid
~)
[download]

It's also easier for us (and you) to read if you can split it up and indent it some logical way. :o) Update: (like dragonchild's *beautiful* example below - definitely gets my ++!)

thx alot serv your q~ ~ stuff works
kind regards

my $sth = $dbh->prepare( <<'__END_SQL__' );
SELECT smt.uniqueid
      ,smt.creationtime
      ,att.name
      ,att.val
      ,gsm.msisdn
  FROM dagenericsmt smt
  JOIN dagenericsmtattribute att ON smt.uniqueid = att.genericsmt_uniq
+ueid
  JOIN dagsmproduct gsm ON smt.product_uniqueid = gsm.uniqueid
 WHERE smt.smtstatus  = ?
   AND smt.smtcommand = ?
   AND smt.acktime   IS NULL
   AND att.name      IN (?,?)
 ORDER BY smt.uniqueid
__END_SQL__

$sth->execute( 2, 3, 'GSM/Cur/IMSI', 'GSM/Rpl/IMSI' );
[download]

• I'm using Perl formats to lay out the SQL statement the way it would be laid out by a DBA in a .sql file. This allows you to cut'n'paste the SQL statement to an email to a DBA and not have to reformat it. Unless the DBA really likes you, s/he won't even look at what you have in your version. They have enough to do.
• I'm using DBI placeholders. They give you two things:
  1. They allow you to reuse the same $sth for multiple values, avoiding additional statement parses. This reduces the load on both the application server and (potentially) the database server.
  2. They allow DBI to quote your strings, thus making SQL injection attacks impossible.
• I'm using SQL's JOIN feature vs. doing the table JOINS in the WHERE clause. This does two things:
  1. It's now easier to see what's involved with joins and what's involved with restricting the set to be returned. Before, it was just a jumbled mash.
  2. Most databases (including Oracle) can process a query more efficiently if they see the joins separate from the WHERE clause.
• All the SQL keywords are in uppercase, making it much easier to understand what's happening. Also, everything is indented nicely, meaning that your eye has to do less work to see what's going on.

Yes, it takes a ton more lines. It's also more maintainable. If you had to make a change to the query, would you rather do it to yours or mine?

thx for your reply ;D well im the DBA here and your right if someone send me this i wouldnt look @ it ;D i will try your suggestion and will come back with the results ;D <--- perl nub btw ;D