PFMaBiSmAd

Why don't you just directly store the images at the final destination as has been suggested? What you are doing now won't work when you have multiple concurrent visitors because the intermediate output filenames are not unique and files can get overwritten before you copy them to the final destination.

You do realize that most people on a forum won't click on links you put in your posts. Just copy/paste the error message into a post to get the quickest solution.

Your code is reusing the $image variable to hold the GD image resource, so when you use $image later in the code as the name for the file, you get files named like Resource id #10... I suspect that the code wanted to use the $destination variable as the second parameter in the imagejpeg(), imagegif(), imagepng() statements so that the resulting images would be stored directly in the destination.

Search for: DocumentRoot

Update queries, as you might imagine use the UPDATE keyword in them, not the INSERT keyword. Your code does not have any error checking or error reporting logic to test the result of the mysql_query() statement, so it would be a little hard for your code to tell you if the query did fail. mysql_query() returns a FALSE value if the query failed due to an error. You would also need to check mysql_affected_rows to determine if the query actually updated the row (after you change the INSERT to UPDATE in the query.) If this is a real application (not just something in a programming class), you must both check in the form processing code that the current visitor is authorized to update the record with the id that was passed to the code and you must also validate/escape the data values being put into the query. Also, in looking at the query, the red part in the following makes no sense and is invalid- username (user_id, username, password)='$ud_username'

It's likely that your web host originally had a different folder structure set up and/or your account got moved to a different server and what you currently have for DOCUMENT_ROOT is the definition that was written to your vhosts file when your account was created. Your web host would need to correct the document root setting.

affected_rows is only relevant for INSERT, UPDATE, or DELETE queries. num_rows would be used with a SELECT query. $statement->execute() returns either TRUE on success or FALSE on failure. You would probably want to test that to determine if the query produced an error or not and then $statement->error would tell you what the error was.

A) Exactly where are these files being created at, what folder? B) Your code is apparently using a file handle or a database link resource as the file name to save a file as and you would need to post your code if you want help with it.

The HTTP response to a HTTP request can only consist of one file. You must generate a separate HTTP request/response for each file.

Whichever method you choose to do this, don't automatically update the existing password in the user table until the user performs some action using information you send him in the email. Otherwise, someone can just go through a list of likely/actual usernames requesting a new password and screw up the accounts of your users.

That error means that your query failed, due to either a problem with the database connection, with the table/columns, or a syntax error in the query. Unfortunately, using or trigger_error() (using or anything()) in code is only useful for troubleshooting purposes because it does not address the code execution path when an error does occur. Also, what trigger_error() does is dependent on the error_reporting/display_errors/log_errors settings. Are you doing this on a system with error_reporting set to E_ALL so that all the errors that are detected would be reported (the default for trigger_error() and what the code you are using does would be to generate a NOTICE level error.) Also, your code is not setting $num_rows (you would be getting another NOTICE level error when it is referenced), so the code will always display 'No Titles Found'. And the }else { logic that is retrieving the results from the query (where your current WARNING level error is at) is part of this test if (count($error) < 1) { , so it (the code retrieving the results from the query) will be executed when $error does have a count of 1 or more, and not when the query returned some matching rows. Edit: Actually, based on the last paragraph, the error is because your query has not even been executed at the time you attempt to retrieve the results from the query because of the incorrect logic in your code..

With a very bad database design and with only a small amount of data, it might be possible to produce a situation where php code could search through some data faster than a database engine could, but this would also require that the specific data be cached and not actually retrieved from the database before each search. If you are going to the trouble of executing a query to select data, you might as well get that query to select just the data that you want, in the order that you want it, and with anything like date/number formatting already done so that your relatively slow parsed/tokenized/interpreted php code only needs to iterate over the data and display it.

There are not very many ways that you can write to a server's disk without some kind of authorization or a helper service/application/script present on the server to perform the action. I would recommend that you ask your friend for a verifiable example or a working demonstration of how he believes this can be accomplished. Just a general unsubstantiated statement that enabling mod_rewrite allows writing somewhere on a server's disk is, well, unsubstantiated.

Method A) will always be at least 10x more efficient than using php to perform the same task. The database search engine is compiled code. Php is a parsed/tokenized/interpreted language. Also, retrieving all the data into php every time you perform a search using php code would be many times more memory intensive because you must now transfer all that data to the mysql php client and then fetch it into memory that is accessible to php.

All string data values put into a query must be escaped so that any special sql characters in the data don't break the sql syntax and to prevent sql injection by hackers. See this link - mysql_real_escape_string

Here is a HTML DOM class that makes finding specific data on a page easy - http://sourceforge.net/projects/simplehtmldom/

In real applications, especially involving money, data is never actually deleted (unless whoever assigned this to you wanted to see if you could research, define, and create code to actually delete the correct records.) You would normally just mark accounts as closed in a status field and not include them in any active queries (except in a list of closed accounts.)

Any chance you are switching back and forth between URL's that have and don't have the www. on them and/or the URL's have different paths to the files in question? The session.cookie_domain and session.cookie_path settings affect if the session id cookie matches only the subdomain/hostname (www. or no www.) and path where it was set or matches all variations of the subdomain/hostname and path on your site. What does a phpinfo(); statement show for the session.cookie_domain and session.cookie_path settings?

Did you bother to read the error message? It has nothing to do with the session_start() nor is it even a header error - The path you are using is not valid. The leading slash / you are using refers to the root of the current hard disk.

Does your web host support the LOCAL version - LOAD DATA LOCAL INFILE?

mysql_query() returns a result resource. You must fetch the data from the result resource before you can use it. There is a family of mysql_fetch_xxxx() functions that will let you do that. I recommend reading a basic mysql tutorial or read the examples in the php documentation to learn how to execute a query and fetch the data from the query.

Frankly, you are gong to have to debug what your code IS doing on your web host to pin down at what point during it's execuition you have the expected results and at what point you don't. I can guarantee that the problem lies between those two points. You have not provide enough information about the actual symptoms, the code responsible for those symptoms, and at what step while navigating through your pages that the problem occurs at for anyone here to directly help.

W H A T Log in string? If that statement refers to a query, it's likely your queries are failing because of different database structures and you don't have any/enough error checking in your database code to get it to tell you if or why it is failing.

Time is fairly precise. Are you sure you have a matching row where your time column has a value that exactly matches what is in your $time variable? Generally when trying to match time, you use <, <=, >, or >= comparisons rather than just an = comparison.