gizmola

Did you take a look at http://us.php.net/manual/en/function.ziparchive-extractto.php

I would avoid storing blobs in mysql due to the substantial overhead of getting the file data into/out of the database. In essence this is double the overhead of just storing it on the PHP server, although if you have a cluster of servers, this can also become a problem. As for PHP, it uses the $_FILES superglobal to store information about the HTTP post that includes the uploaded file. PHP sticks it in a temp directory, and it's up to you to call move_uploaded_file() and give the file a permanent name and location. Typically this is where people store the location of the file in a database. There's plenty more to be said about this topic, however as for a few tips and places to read, I think this should get you going.

$piece1 = trim($array[0]);

This really isn't how PHP works. PHP has a hashed symbol table. I doubt there's any noticeble difference, but technically there is probably a little bit more overhead in parsing: $arr[0] compared to $arr['0'] -- that overhead being the need for PHP to check that zero is not a constant. With that said, I would never bother to use $arr['0'] even though internally I know that all array indexes are strings.

No, you get a one dimensional zero based array. So: $piece1 = $array[0]; $piece2 = $array[1];

Ok, so just to clarify, I agree with AlexWD's comment -- mysql themselves state that their internal encryption algorithm shouldn't be used to encrypt passwords. As for quibbling, md5 and sha1 are Hashes. They are not encryption per se, because they can not be decrypted. You give a hash an input, and it will create a hash, such that it is impossible to derive the original input given the hash. They should also have the property that it should be impossible to guess what the hash value is. Using PHP's mcrypt extension you can use heavy weight encryption/decryption if you want. This is a topic that is endlessly debated, as some people will insist that you should use hashes and not encrypt/decrypt routines, as this will insure that even if your server is compromised, people will not be able to reverse the original passwords. Using a hash for a pw is a pretty standard alternative, but if you are going to use it, it's a good idea to hash a string that is comprised of more than just the password itself. For example, using the username + pw + "a salt" would be a lot better input. i won't explain what a salt is, but you probably want to read up on the idea if you intend to implement your own hash based password routines.

Check out xdebug.

It appears to me that you are doing things correctly by including the user specific id to the where clause in subsequent queries, once you've logged the person in. As far as having row level security, very few databases offer that, and it comes at a high cost both in terms of monetary cost and performance. Your approach is both standard, and effective.

That sounds like a good approach. While that would require some javascript, it would not require AJAX per se. As for seperate divs, you really don't need to do that. Just load the inventory into a javascript array or seperate variables, and when the drop down changes you can update whatever html object you're using to display the value.

I'm confused by your original explanation. You say that you have a Database named Game -- do you really mean a "Table". The SQL indicates this. Then you say that each user has their own table, but really all the rows are in the same table -- correct? Sessions are the solution to the problem in web development of not having a session between requests. All that sessions do is (in practical use) push the user a cookie with a session ID. Data that is stored on the serverside in session variables gets serialized and can be used on subsequent requests. So it does seem that what you're really asking is, how to authenticate a user. Once you've authenticated that user you can store other information in their session (id, gold, etc) and use it in displays. I'd recommend you use the "id" (assuming it's the primary key) for any subsequent access (say for example you need to update the amount of gold in a query based on something the user does during the session).

Yes, you have to restart the mysql process under linux. There's a variety of ways to do it depending on the distro, from getting to a shell, finding the parent process and sending a kill, to doing service mysqld stop in RHEL and Centos distros. To restart with CPanel, you need to use the WHM interface. At the bottom there's a restart services section, and one of them is Restart SQL Server, which willl restart the MySQL server.

The best practice is to keep classes in their own php file, named with the same name as the class. This also facilitates simple autoloading, if that idea appeals to you, and for the price of a bit of overhead, you won't have to worry about manually requiring class files.

Yeh sure, there are a limited amount of tutorials located there but how can members teach there own content related to PHP or whatever, i personally think there should be a board where users can submit there own tutorials and other members can actually learn new things. Regards, Ikram Ikram, Anyone can write tutorials and submit them to the tutorial section. The moderation group simply reviews them for correctness, but that's a minor hurdle in most cases.

Under the circumstances, I think it's a good idea for you to implement the HTTP Listener. It makes your server easier to work with.

Yes, something is wrong in all probability. I would suggest you restart mysql and see if that frees things up. SQL statements are the best approach to making DDL changes like table renaming. You don't know what assumptions might be built into a tool, and it's possible that the tool created a lock somewhere and this is what caused your issue. FWIW, I think the safest and best way to do what you did is: CREATE TABLE results_archive AS SELECT * FROM results when results_archive is done you can then either drop table results or truncate table results if you want to empty out the data and begin to use it again.

Either approach will work, but iframes were really designed to allow the integration of content from separate websites.

Converting to Json will reduce the overhead of your xml calls. With that said, you are only needing 1 function call and an assignment. It's not that bad.

Is this a detail page for the individual item? If so, I don't see why you wouldn't load up the information when the page is generated. No Ajax would be required.

With PHP there is no need to include the end tag, and there are even advantages to not including it. With that said you might want to make sure that the file didn't already have that definition in it. So one way to handle it is to read the file in first, and if you determine you need to modify it, then open it for rewrite and write out the entire contents, along with changes.

defs.php is just code. Those are php constants that get set using php define(); I don't know what you mean by "add salt to that file" but in terms of code, you can edit any php file using a simple text editor.

the errors probably are going into the apache error logs for that server. If it's a linux server, you might check /var/log/httpd/...

Bah Humbug

Seems like you got a pretty descriptive error. The user specified does not have access to the database specified.

The simplest way is to have an activation table. You create a row on activation, and this table has the userid, created, activationcode and activated, which can be a tinyint you default to 0. Usually the code itself will be a hash value -- md5 or sha1 typcially. You can use the useremail+date+userid+salt to get a good input value for our validation script. When the validation script is called it should only accept the single get param of the activationcode. In the script simply look up the row in the activation script. You have these possiblities: -Not found (error) -Found (Already activated) (expired) -Found (unactivated) -- Do account activation, update and set 'activated' = 1. You can also use the created flag to limit the use of old activation codes -- for example, you might check to make sure that the activation is within 48 hours and choose to disallow activation on that basis.

Yes, sorry I missed out on what you were saying. Is there a rule that governs the size of the prefix?