PFMaBiSmAd

In your original thread for this problem, the reply that was posted showed you how to get a count in the (each) group.

What exactly does it do? In programming, it is always best to troubleshoot and find out what is causing a problem and fix it, because all the other WAMP like packages could behave the same way if the problem is something to do with your computer or your code and you could just end up wasting a lot of time trying things that have nothing to do with the problem.

BTW, I just tested your code and it 'functions' as expected, with no changes to the common.php code. All I added was a simple DB class, an instance of the db class in $DB, and the actual table in the database. Your index.php displays the following expected output for each refresh of the page - array(1) { ["count"]=> int(38) } 39 array(1) { ["count"]=> int(39) } 40 array(1) { ["count"]=> int(40) } 41 ...

^^^ That line looks suspicious. In most db classes, the query would return a result object and you would use a call like $query->num_rows() to access the number of rows. Have you actually tested the logic in sess_read() by calling it directly to see if it does what you expect for an existing record? Your sess_gc() logic is backward and probably won't ever delete anything or it will delete things that have a future (>) expire time. You probably want it to delete records where the `session_expire` < '". time() ."' Your overall use of `session_expire` is a bit unusual. By setting it to a future time (rather than setting it to the current time when a record is accessed) any time you change the session.gc_maxlifetime setting, the change won't affect existing session data records because their session_expire was already determined when they were stored, not when they are referenced. You can replace (pun intended) most of your sess_write() code with a single REPLACE query. There's no need to run a SELECT query to decide if you should run an UPDATE or an INSERT query. And you do realize that using some relatively slow parsed, tokenized, interpreted php code to do the session handling is ~10 times slower than using the built-in compiled file save handler, so you would need to have a really good reason to use a database session save handler.

Use - ORDER BY FIELD(name,'funny','amazing','video')

You have got to use the post method to upload files - method="post"

A SELECT query that executes without error returns a result resource. Why on earth are you echoing "fetchdata: $fetchdata<br>Failed with error: " . mysql_error() . '<br>' INSIDE the while() loop that will only be executed when the query executed without error and there is at least one row in the result set.

The error message, that you didn't post, tells you where the output is occurring at that is preventing the header() from working. I'll guess it was a line in the htmlheader.php file? You cannot output any characters to the browser before you use a header() statement and if you are going to redirect the browser, there's no point in outputting anything, even if it did work.

Without a complete set of code that reproduces the problem, it will be a little hard to help with the problem. It could be your database class, your session_set_save_handler statement, a program/variable scope problem, your php code that is attempting to use the session variables...

settype() doesn't return the data, it returns a true/false.

How about displaying all your post/files data to see what you are getting - echo "<pre>"; echo "POST:"; print_r($_POST); echo "FILES:"; print_r($_FILES); echo "</pre>";

http://www.php.net/manual/en/features.file-upload.errors.php

Your code needs to test the $_FILES['thumbNail']['error'] element to determine if an actual file was successfully uploaded, because the ['name'] element will be set to a value for several of the possible upload errors.

The only code that was relevant to the problem is the INSERT query that is failing and producing that error. The error means that the number of fields listed and the number of data values don't match. You would need to determine if you listed the wrong fields or the wrong amount of data values. Edit: And why on earth did you quote your own entire post just to state you solved the problem?

How did the data value get inserted into your table? You likely have a new-line (cr/lf) or a null byte (zero) or even a space stored as part of the data. You will need to find out what is causing the value in your column to not match the expected value you are using in your query.

Did you include the Class definitions that are part of that library into your code before you attempted to create the instances of the Classes?

Can't get WHAT to work? What session.php? You haven't shown the total code that would be needed to produce/reproduce the problem, what it actually did vs what you expected, what exactly session.php is, or what the whole error message was.

LOL, upon further review, I see the one in your posted code. You are not setting the 'path' or 'domain' parameter(s), so the cookie will only be available at the same exact path and host-name/sub-domain where it is set. In your actual code on the live server, are you switching either of those things in the URLs when you navigate between pages that work and don't work?

On the actual code on your live site, the page that 'forgets'/resets the language setting when you navigate to it is either having a 'header' error that is preventing the session_start() from working or you are switching the host-name/sub-domain back and forth between a URL that has www. on it and a URL without a www. on it and your session/cookie 'domain' setting is not set to match both URLs or you are switching the path in the URL and your session/cookie 'path' setting is not set to match both paths. What does a phpinfo() statement show for the following settings on both your development system and the live server - output_buffering session.cookie_domain session.cookie_path It would also help if you showed the setcookie() statement you are using.

The fastest way would be to explode it on the / character and then just put the pieces back together the way you want.

I'm going to guess that your 'absolute' file path was actual a URL. Any chance you were using something like http://your_domain.com/kinnect.php in your require_once() statement?

Unfortunately, php.net itself took the position that completely suppressing some types of errors and hiding error messages in general was an acceptable programming method, even when learning and during development (it is only in php5.3 that the php.ini suggests settings specifically for development), and the makers of the all-in-one development systems (they are not intended for any other purpose) blissfully and unknowingly followed along and distributed systems that hindered the efficient creation of php code during development and for those trying to learn the language. We have seen countless posts on the forum where the error messages, had all of them been reported and displayed, would have saved a TON of time by pointing out things like typos, missing parameters and values, wrong information/usage in the code, and other basic problems that everyone makes while learning a programming language and while writing code. In just about every one of the 'my code is not working and there are no errors being shown' posts, the first reply is a suggestion to set the error_reporting and display_errors settings to get ALL the php detected errors to be reported and displayed so that there is SOME information upon which to narrow down and find what is causing the problem. Php scripts should not produce any php detected errors of any kind during their normal execution. Scripts should only produce php errors for unexpected things, which should be logged on a live server, like a legitimate visitor entering an unexpected value that your validation logic did not deal with, the hacker feeding your code all kinds of unexpected data in an attempt to break into the script, the mail/database server that sometimes does not work or that got reconfigured and is preventing your script from using it, the remote server you are trying to access that is not working, ... You do want a record of errors caused by these type of things, but these are the only errors you should see in your error log, not 100's of thousands of warning/notice messages because your script produces a couple of dozen errors every time it runs. P.S. Scripts run a tiny bit faster and use less server resources if they don't regularly produce errors that have to be handled by the php language engine (even if you don't report, log, or display the errors, php must still deal with each one them every time they occur) and writing lines to the error log file adds processing and disk overhead every time php does it.

^^^ You would probably want to find and fix whatever is actually causing that. Databases of 10's of millions of rows shouldn't take that long to retrieve data from.

I would also ask, how big is the generated data, because you might want to consider saving the resulting 'file' in a session variable so that you can use AJAX to display the progress bar and then once the file has been completely generated, javascript can be used to make a request to your 'download' script that gets the file from the session variable and outputs it. What you are asking takes multiple http requests/http responses, because the only thing you can output for the request/response for the downloaded file are the headers followed by the file data.

Just exactly how long does it take to produce the output data and if it is more than a second or two, why does it take that long?