file upload as "idnumber".bmp

[matt]

Any help appreciated.

I have a form that does pretty well to collect data and upload a
persons picture to a directory on a server.

The part of the form that does the latter is:
copy($HTTP_POST_FILES['PhotoUpload']['tmp_name'],

"directory/pictures/" . $firstName . " " . $lastName . ".bmp" );

-------
So the file will save on the sever as "firstname lastname".bmp

But of course when people with the same name register, there is an
overwrite, plus for another application I would like the photo name to
be "idnumber.bmp"

At the moment the server adds a new id nuber for each line added to
the database and so there is a variable passing around called
$idnumber

I thought that I could make the above changed to this:

copy($HTTP_POST_FILES['PhotoUpload']['tmp_name'],

"directory/pictures/" . $idnumber . ".bmp" );
------

but this doesn't seem to work because I don't think that this value is
given a value until everything is posted to the server - which makes
sense because the id number is the unique incremental value given to
each row of the database.
Does anyone know how I can change this form to get it to do what I
need?

Thanks for any help

Matt

[Mike P2]

On May 4, 4:01 pm, [e-mail] wrote:

Does anyone know how I can change this form to get it to do what I
need?

Thanks for any help

Matt

You have to move the uploaded file after you insert whatever it is you
insert into the database so you can get the new ID number. The most
efficient way of retrieving this incremented ID depends on how you are
connecting to MySQL. If you are using the regular MySQL interface, you
can get the ID number back out by using the mysql_insert_id() function
immediately after your INSERT statement. If you are using MySQLi (non-
procedural version), you can use $MySQLiObj->insert_id.

Also, when dealing with uploaded files, for security reasons it's
usually best to use the move_uploaded_file() function instead of
copy(). But you may already be checking the uploaded file using
is_uploaded_file(). move_uploaded_file() just does both at once.

So here's an idea of what should work:

<?php
//...validation, DB connection, etc...

if( !$db->query( "INSERT INTO `it` ( `...`, `...` ) VALUES ( '...',
'...' )" ) )
{
$uhOh = "Query failed: $db->error";
}

else if( !move_uploaded_file( $_FILES['PhotoUpload']['tmp_name'],
"directory/pictures/$db->insert_id.bmp" ) )
{
$uhOh = 'Could not move uploaded file';
}

//...
?>

-Mike PII

[shimmyshack]

On May 4, 11:32 pm, Mike P2 <[e-mail]:

On May 4, 4:01 pm, [e-mail] wrote:

Does anyone know how I can change this form to get it to do what I
need?

Thanks for any help

Matt

You have to move the uploaded file after you insert whatever it is you
insert into the database so you can get the new ID number. The most
efficient way of retrieving this incremented ID depends on how you are
connecting to MySQL. If you are using the regular MySQL interface, you
can get the ID number back out by using the mysql_insert_id() function
immediately after your INSERT statement. If you are using MySQLi (non-
procedural version), you can use $MySQLiObj->insert_id.

Also, when dealing with uploaded files, for security reasons it's
usually best to use the move_uploaded_file() function instead of
copy(). But you may already be checking the uploaded file using
is_uploaded_file(). move_uploaded_file() just does both at once.

So here's an idea of what should work:

<?php
//...validation, DB connection, etc...

if( !$db->query( "INSERT INTO `it` ( `...`, `...` ) VALUES ( '...',
'...' )" ) )
{
$uhOh = "Query failed: $db->error";

}

else if( !move_uploaded_file( $_FILES['PhotoUpload']['tmp_name'],
"directory/pictures/$db->insert_id.bmp" ) )
{
$uhOh = 'Could not move uploaded file';

}

//...
?>

-Mike PII

mike has answered already, im just adding an off topic point, when you
say "another application" do you use the same table to authenticate
both sets of users as well as the same table to store data regarding
pictures and so on, if you do remember that while one app might be
"aunty mable's semi-naughty hen night shinanigans" the other might be
"important child protection work data" one day you might create a test/
test account for auntymabels friends who says she cant login, and
anyway you won't require strong passwords on the mabel app cos its
only a bunch of computer-phobics. This adds up to, cross contamination
of data, sql injection based on same privaledges for the mysql user
for boths apps, increasing the surface area for easy hacks to occur in
both apps.
It would be safer to [create a new db per app and] copy the table when
sets of users unmixed, and give each app a non-privaledged user which
just has usage of that particular app's auth table.
(I once knew a man from london whose mysql server was completely
undone - no honest I really did, for this very reason)
ttfn, m