Jump to content


  • Posts

  • Joined

  • Last visited

Posts posted by hitman6003

  1. Sessions use a cookie (by default) to store a session id, which the server then uses to reference data stored for the identified session (stored in the server's temp directory by default).


    The cookie is lost when the browser is closed, which means that it will no longer be passed back to the server on subsequent visits, and the data is no longer associated with the user.  The data is lost after a configurable period of time, I seem to recall that 60 minutes is the default.


    When you say you "ran it independently of the first one", were you using the CLI or a browser?  Sessions do not apply to CLI scripts.

  2. I don't think you can migrate between Windows and Linux...I believe they treat endian numbers differently which breaks binary compatibility.


    If it will work, you must use the same version of MySQL if possible...at a minimum, at least stay in the same minor revision series.  In other words, you can't go from 4.x to 5.x, or even 5.0 to 5.1 in most cases, but you can go 5.0.45 to 5.0.67, and so on.

  3. See if your database contains any "\n" or "\r" characters.  These are ignored by the browser, but depending on how you're viewing the database will show up correctly (replaced by an html line break) or as a space.


    echo str_replace(array("\n", "\r"), " ", $database_row['fieldname']);

  4. You probably aren't getting an error, but rather a notice.  These are harmless, however they usually point out small "good practices" in your code that need to be fixed.  The one you are encountering is when you use a variable that hasn't been defined before.


    You can turn off notices by doing this:


    error_reporting(E_ALL ^ E_NOTICE);


    or you can define a default value for query...at the top of your page, put something like:


    $query = "Unknown";
    // ... rest of code


    or you can have a check where you print the value of $query...


    <?php print (empty($query) ? "unknown" : $query); ?>

  5. It's MySQL instance specific, you set it in the my.(cnf|ini).


    Most of the time it's already enabled, but there is no memory devoted to it...give it some memory like so...


    -- the value is set in bytes, so the below is 16 MB
    SET GLOBAL query_cache_size = (1024 * 1024 * 16);




    I think you might have to have the SUPER privilege to modify the global query cache...not sure.

  6. It tells you what the problem is:


    Field 'username' doesn't have a default value


    In order to be a primary key the column has to be both unique and non-null.  You don't have to set a default value (and you shouldn't in this case), but you have to insert something into that column EVERY time you issue an INSERT statement against it.


    Why are you using a text field as a primary key anyway?  There are times when it is appropriate, however this isn't one of them.  Because you are using it as a foreign key in another table, that means it must be duplicated many times over.  This leads to storage bloat and very large indexes.


    Look at it this way..."username" is probably a VARCHAR, and probably ~ 30 characters in size.  This means that for every record in that table, the index uses 30 bytes to store it...in addition to the actual storage on disk for the tuple's data.  Now, when you use that column as a foreign key in another table, you (should) have an index on the foreign key column...another 30 bytes.  If it's an InnoDB table, each additional index stores a reference to the primary key (30 bytes x # number of indexes)...


    Even if you only have the two indexes...primary key and foreign key...imagine how much RAM the indexes will consume if you have a million users (60 MB)...just for one table!

  • 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.