With which parts of the PHP do you have problems?

For database access, DBI is the closest to mysql_query you will get. The translation should be fairly straightforward though.

For fopen, fwrite and fclose, see open, print and close.

I think there is a logic error in the original PHP code, because it seems to always skip the first row of the returned results. There is one mysql_fetch_assoc() call outside the while loop, and unless the first call is just to "prime the pump", that call will discard the first row.

use DBI;
my $DB = DBI->connect( ... connection info goes here ...);

my $sql="SELECT * FROM addressbook WHERE deprecated='0000-00-00 00:00:
+00' AND thumbPhoto IS NOT NULL";
my $recordset = $DB->prepare($sql);
$recordset->execute();
while (my $row=$recordset->fetchrow_hashref){
    open my $handle, ">", "./images/$row->{photo}";
    my $data = $row->{thumPhoto};
    print $handle, $row->{thumbPhoto};
}
[download]

As you can see, the code is very similar. There's a bit of syntax difference between how perl and php access a hash

Notes:

• As you can see, the code is very similar, though there are a few differences. None of the differences are particularly alarming, however:
  • The syntax to access a hash from perl is slightly different than for PHP.
  • Since we're using a different module for database access, the code to set up the statement and fetch the results are similar but different.
  • Similarly, file handling is a bit different beteen perl and PHP, so opening the file and writing the file are a bit different as well.
• I did a translation of code, not intent. You may need to tweak things based on your database definitions, environment, operating system, etc.
• I didn't add any error handling, so you'll want to add some if/when you use it.
• The DBI database interface package is probably (to me) the most useful module. Other database interface modules exist, and some may be more similar to the mysql_ stuff used in php. But if you use DBI, I don't think you can go wrong.
• In DBI the prepare method lets you set up a statement so you can use parameters, which is why it's separate from the execute method. If you do any significant database work, learn to use prepared statements no matter which language/platform you wind up using. You'll be happier that way.
• All done from the top of my head, with no ability to test it. (My current $work PC has neither perl nor DB access any longer.) With luck, I haven't farbulated anything inquoherently.
• Since perl will close the file handle $handle when it goes out of scope, I didn't bother explicitly closing the file.

...roboticus

When your only tool is a hammer, all problems look like your thumb.

After looking past what I thing was probably a bug, the steps for solving this using DBI are:

1. Start your script with use strict; use warnings; use autodie; use DBI;
2. Ask DBI to connect to the database using the DBD::mysql driver, obtaining a database handle.
3. With the database handle, use DBI's "do()" method to perform your query, obtaining a statement handle.
4. Open your output file using the three-arg open.
5. With the statement handle, within the conditional of a while(){} loop, invoke DBI's fetchrow_hashref() method, obtaining a hashref for one query row.
6. Inside the while loop's block, write your output using print in its print FILEHANDLE LIST; format. Use the filehandle obtained by open.
7. After the end of the while loop (outside/after the main block), close the output filehandle using close.

If there is any possibility that this script might be run concurrently with another process that also touches the same output file, be sure to properly flock your output file.

Additional reading: perlintro, open, perlsyn (for a discussion of while loops), perlsub (for a discussion of lexical variables), DBI, perlopentut, print, close, flock.

Each of the seven steps above is a small amount of code. With the exception of step one, we're talking about a single statement or line of code per step. It would take fewer keystrokes for me to just write it for you than it does for me to explain it, but that's not what PerlMonks is here for. This site is for educational, and arguably recreational purposes. Let me know which step you get stuck on, and provide the code you've written so far, and I'll gladly help you get past the tricky part.

Start by very-carefully reading DBI, which is the most-commonly used database interface unit in Perl.   Patiently read this entire document, top-to-bottom.   Rinse and repeat.   Then, spend several more hours today and tomorrow, surfing the web for tutorials.

The biggest difference between PHP and Perl, in this regard, is that with PHP “everything that you can reasonably get to” is compiled into the PHP executable at the time that it is built.   (Which is one reason why, on my system, /usr/bin/perl is a cool 86,000 bytes long, whereas /usr/bin/php is 32.2 megabytes!)   With Perl, you would “use DBI;” in order to gain access to what goodness that module gives you, and that module must be installed on your system (as, in this case, it undoubtedly is).   The core Perl language-interpreter is extremely small, and the system is extremely modularized.   Neither approach to programming-language design is “right” or “wrong,” but each must be clearly understood.

Then, as you can see from the examples in DBI and the tutorials that are out there, it’s pretty basic stuff ... but it is all being done with objects and methods, not built-in functions.   A connect() call gives you a connection to a database and a “connection handle,” which represents another Perl object that has methods such as prepare and execute ... each of which return a “statement handle” (yes, another object ...) that represents the results provided by that statement.   The methods that are available are, of course, very comparable:   mysql_fetch_assoc() corresponds to $hash_ref = $dbh->selectrow_hashref($statement), and so on.   But none of it is “built-in” to Perl.   PHP keeps a lot of internal state-information about its database connections within its own “guts,” and does not necessarily expose them to you, whereas in Perl nothing of this sort is internal to the interpreter ... it’s all done through these objects, none of which are (nothing ever is ...!) “built-in.”

You’ll hear this a lot:   TMTOWTDI .. “Tim Toady” .. There’s More Than One Way To Do It.™   You can easily see that this is the case, just in looking through the list of methods in DBI.

Another thing-to-know about Perl is that you basically must add two statements to your program at the top:
    use strict;
    use warnings;

... because, without them, Perl will try rather mightily to “do what it thinks you want,” and will not tell you about various syntax errors and so-forth.   If you don’t know to expect that behavior, you might not realize that an error had been made, and that the error is adversely affecting your code.

If you are using a “PHP-aware” text editor now, such as Eclipse, then you should install similar Perl-language support into it, as well.

You will find, as you get to know the Perl system, that a lot of it will be very familiar to you from PHP:   there aren’t that many “new ideas” in this world, after all.   Hashes, lists, arrays, classes ... “the usual suspects” ... yet implemented in a very different way.   Importantly, the notion of “mixing HTML with executable code” is absolutely non-existent.