Jump to content

AzaraelIshanti

Members
  • Posts

    10
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

AzaraelIshanti's Achievements

Newbie

Newbie (1/5)

0

Reputation

  1. Well, I am fairly an idiot, you are right. I must've printed the ID from a different page for a similar process. One of the previous MySQL calls was failing and not setting up the id correctly, so yea, it didn't get a value, was trying to pass a ' '. But, while we're both here, I was under the impression that int(2) referred to the number of digits? If not, why does it not have 01 as the value on the database? It just seems to say 1...
  2. The field in this table is not auto-increment, it's based off the auto-increment from another table Int 2 'cause...I'm not planning on having more than 99 users? $id definitely has a value, I even had it echo the whole query, the $id is definitely storing an integer value.
  3. The actual code is posted in the thread. Do you need more of it? I thought I posted the relevant bits. That's straight from the PHP document.
  4. I have no doubt that I'm missing something obvious, but I'm getting an infrequent syntax error from the simplest of MySQL queries. Background info: Table "profiles" has two columns "id" (int 2) and "joindate" (int 10). Stored as an integer on the table 'cause I have no use for the date there, I manipulate it elsewhere in the program. Anyway, not relevant... Here's the query. $rightnow is getting the time and $id refers to the correct (tested this already...) id of the player trying to update their profile. $rightnow = time(); $mysql_query2 = "INSERT INTO profiles (id, joindate) VALUES ($id, $rightnow)"; You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ' 1355098639)' Needless to say I'm extremely annoyed, it seems quite straightforward. I have also run into other random errors with the final value of random simple MySQL queries. Happens about once a month and it's completely inexplicable. I end up COPYing and PASTEing another unrelated MySQL call (which to the eye looks identical...) and simply replace the COPYed values with the new values I'm trying to pass...and it works! But...the end result is, as far as I can tell, identical. But copying a working query and replacing values work, writing a new one doesn't...so I'm doing SOMETHING wrong? Or my MySQL server just hates me... HELP! I'm annoyed!
  5. Somebody mark this as solved, as I'm a complete moron. I believe it was the initial chmod recommended in post #2 of this thread that solved the problem, but as I had complete bungled the original script trying to fix it in the first place, it wasn't working due to my own stupidity. I went through the code top to bottom and found some very stupid mistakes in regards to paths (what was I thinking...?) and it again works. Thank you for all your help and bearing with me. So yea, mark as solved or something... And for future posters...check your destination paths. Wish I had...
  6. I'm trying to determine exactly WHERE the problem is occuring. print_r($_FILES); produces: Array ( [new_file] => Array ( [name] => geico_eyes.png [type] => image/x-png [tmp_name] => /tmp/phpjnTbKx [error] => 0 [size] => 12831 ) ) Does error = 0 mean it successfully arrived at /tmp/phpjnTbKx? Or does error 0 mean it received all the information and it SHOULD be in /tmp/phpjnTbKx?? Consequently, if the file cannot be moved via move_uploaded_file() should there be some kind of error or warning associated with it being the wrong permissions? I get no warnings or errors at all...where did it go wrong??
  7. I figure it might have something to do with it being the wrong group. GoDaddy has CPanel which allows you to add a "Domain" to the server. I addded the domain, and it created a new account with FTP permissions and such to the root HTML page and made that root folder the default folder when you go to the site itself, etc etc. What group should it be set to and how can I check if that's what it is or is not set to?
  8. I've never gotton any errors of any kind, that's what baffled me. I have it spilling output trying to debut it. print_r($_FILES); no errors I'm outputting the $path, $filename, etc, everything is correct, and the script runs with no issues locally on the Wamp stack. Just once I upload, it won't work. I did the chmod and the is_writable() now says all the directories are writable...but still nothing.
  9. I ran the script (you forgot a right parenthesis, btw, took me 5 minutes to figure out why it wouldn't run ). It was not writable. So I SSH into the server, I "chmod -R 0777 /path/to/webpage/root" (obviously with the correct path...) because there are a number of directories that need to be able to upload into, and the script says it is now writable. ....however the files are still not showing up after upload.
  10. I think this forum is the best fit for this topic... I've been coding in PHP for the better part of 2 years now and have a rudimentary grasp of what's going on. I recently was asked to administrate a friend's new Red Hat-based virtual server from GoDaddy, and things have been going swimmingly...until I attempted to hook in a PHP file upload, only to find that it will not move the files to the specified destination. I'm getting an error of 0 for the $_FILES array, and when I run the script locally, it successfully move_uploaded_file() to the correct location (running Windows/WAMP Stack locally). However, duplicating this on the virtual server, there is no error or warning of any kind from move_uploaded_file(), it simply is not showing up in the correct directory. I've checked capitalization, I'm completely stumped. I figure it's probably not a fault with PHP, as I've scoured the php.ini file and found all references to File Upload to be ON. It probably has something to do with directory permissions in Linux, but I'm still a novice at all that. Any and all suggestions/help would be greatly appreciated. Thank you.
×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.