Mchl

I believe you typed in a . instead of a , after 'PHPSESSID' Besides, what's the point of setting such a cookie?

Any variable declared in global scope (that is not in the body of a function, a class, or class method) gets included into $GLOBALS array

I'm also pretty sure that the script was executing correctly to the end. It was browser that would probably reset the connection. As far as testing command line scripts, if you use an IDE you're usually an F6 away from running your script, and from the console - up-arrow away.

Seriously. Do it from command line.

Bookmark php.net and visit it often. Even if you think you know some function well, it might be insightful to read about it manual.

More than that, it's called before the class is actually defined.

Not really. In PHP you can create public properties on-the-fly by assigning a value to them.

Chenage $meta = mysqli_fetch_field($r, $i); to $meta = mysqli_fetch_field($r); (each call of this function will fetch information about next column) In general mysqli_ functions are a recommended way of working with MySQL server versions newer than 4.0. It can use mysqlnd native driver (snce PHP 5.3 which can give some performance gain). It has a built in support for transactions, prepared statements and other features introduced in MySQL 5.x. It provides a slightly better API, so that you're less prone to create silly bugs. Last but not least it provides an object oriented interface, which can be extended for better code reusabilty.

And in mysqli it's first and required. I really advise sticking to mysqli. The database is selected in mysqli_connect

Are you running this from your browser? Don't. Run it from command line.

1. yes ALTER TABLE yourTable AUTO_INCREMENT = 1400 2. yes, but be careful with that

And just to demonstrate how the original code can exploited: page.php?id=12345' OR 1;-- so your query will be UPDATE tbl SET live = '1' WHERE id = '12345' OR 1;--' which will set live=1 for all rows in database

Like $position = ($page - 1) * 8 + $row ?

No you don't. You need to add another column that you will use for sorting/ordering.

Change your go-pear.bat file to this: @ECHO OFF set PHP_BIN=php.exe %PHP_BIN% -d output_buffering=0 -d phar.require_hash=0 PEAR\go-pear.phar pause

Here was a proof I can't read [edit] It seems that this can happen, if MySQL runs out of space on hdd to store temporary data. Check if there are no filesystem quotes that could be limitng MySQL's disk use. Which MySQL version is that? What is search_log table's storage engine?

I can't see how using a forum would be better than ANY 'standard' VCS. You might just as well use pen and paper.

Because I understood, that you're having the problem with layout that will be printed out correctly by your dot matrix printer. If it's not the problem, then what is?

I suggest you use some other software (even OpenOffice will do) to create a PDF that prints correctly on your printer. Only then recreate the layout using FPDF/TCPDF/or any other PHP library. Should save you some time.

Recycling IDs, or shifting them around is no kind of 'optimisation' and is not a good idea at all. Just let the auto increment machanism do it's job, because it does it well. By recycling, 'squeezing' or otherwise messing by hand with these ids, you're likely to corrupt referential integrity of your data sooner or later. You say you're getting into 6 digit numbers (if I understood correctly). It's not that much. INT UNSIGNED can store numbers p to 4 billion so 4000 times more. How soon you're going to hit that limit? And even if you do, you have still BIGINT with 4 billion times larger capacity than INT. If your database ever grows big enough to require BIGINT primary keys, you'll probably be a rich man by then and will be able to afford a database engineer to deal with such worries for you Other thing is, you shouldn't mix up primary key with record ordering. Primary key is for maintaining referential integrity. If you need your rows to be ordered in particular order (like to put orange between the banana and the peach) you should use a separate column for that. Shifting primary keys for that is 1. dangerous for referential integrity, 2. will be slow (imagine updating several thousands or millions of rows).

They aren't. It's all done server side.

I would advise to use InnoDB mostly because it's a crash safe solution and in most situations performs equally well as MyISAM. The only reason to use MyISAM nowadays (IMHO) is it's full-text search feature (which is absent from InnoDB, but you can use external software to provide this functionality).

In recent versions InnoDB's performance is very often similar or even higher than MyISAM's, although it can ary greatly with the actual queries being run. I will argue, that for sessions table InnoDB is likely to bring some performance improement due to it's row-level locking, and I presume this table is often written to by many concurrent users.

Why do you look for 'alternatives" anyway?

What you do with this data afterwards?