PFMaBiSmAd

The problem is likely in a conditional statement in your code, posted in your existing thread for this problem. You need to be testing if $i == 1 not if $i == i

Nothing I wrote was db-centric. Setting/clearing a server-side session variable to indicate the logged-in/logged-out state is perfectly fine for a simple log in script. A more advanced log in script, with user permissions/roles, a remember-me feature, or the ability to ban users would require that you store the logged in state and permission information in your user table and query that table on each protected page to identify the user (remember-me feature) or to get the user's current state/permissions. Get your current log-in/log-out script working first.

I didn't go through your code completely, but it appears you have multiple blocks of code responsible for handling the submitted form data. You should put that ALL together within one conditional statement testing if the form has been submitted. Since uploading a file can cause both the $_POST and $_FILES arrays to be empty if you exceed the post max size setting, it is customary to test if $_SERVER['REQUEST_METHOD'] == 'POST' to detect if an upload form has been submitted - if($_SERVER['REQUEST_METHOD'] == 'POST'){ // all your form processing code would go in here... } You also need an exit; statement after each header() redirect to prevent the remainder of the code on the page from running while the browser requests the new page.

Do you have php's error_reporting and display_errors set so that you would know if your session_start() statement is working or not? The session_start would need to be successful before you can modify or delete the corresponding session data. Also, your session_set_cookie_params settings is not setting the cookie path to anything, so the session id cookie will only match the path where it was set. You can then only access that session data in the same path where it was set at. If your log-out code is in a different path from the log-in code, you won't we able to destroy the session data. You should normally set the cookie path to '/' so that the cookie will match all paths under your domain. Also, you should not care if regular/session cookies exist or not to determine if someone is logged in. You should be solely using a value on the server to determine if someone is logged in or not. Doing so will mean that you don't care if a cookie exists or not and you won't need to waste time trying to delete cookies (anyone can make a copy of a cookie and restore it after you have deleted it.)

A huge table would start at about 10 to 20 million rows and if you did need to manage that many rows, you would use things like partitioning to get the database engine to transparently manage the data. You would not directly attempt to manage the data in your code and queries. So yes, all the same meaning data should be in one table.

Its likely that the page is being requested twice or you are redirecting to the same page and you are just seeing the result of the second page request (no post data is present.) By echoing some output, you are preventing the second request for the page. What's your whole code on the problematic page?

Your goal would be for your query to return an array with the keys and values that you need. Then simply json_encode that array. You should be using one joined query to get all the related data in one query. Without more specific information from you, not possible to directly help.

Php is a (web) server side scripting language. In order for the web server to invoke php, you must make a http request to the web server. file:///C:/wamp/www/info.php is a file system path and simply tells the browser to open the file. No web server is involved.

What URL did you use in your browser? It should have been something like - http://localhost/info.php

Table names don't have single quotes around them. You also should not have separate tables for each cat/category, requiring you to use the result from one query as the table name in another query.

Persistent database connections only work when php is running as a server module, not when php is running as a cgi application. Are you sure trying to use a persistent connection would have any effect on your server?

^^^ Why do you have that line of code in your program? It is fetching and discarding the first row from the result set.

The get specific rows within a group, see this link - http://mysql.tonnikala.org/doc/refman/5.1/en/example-maximum-column-group-row.html

out is a reserved mysql keyword and would need to be enclosed in back-ticks to prevent an error in your query. Your query error checking logic would have been giving you an error near the first use of out in the query.

If your design expects a specific list of `house` values, it will be much simpler to just clear the `owner` value, rather than to delete the row. To add an owner to the first available `house` value, you would just use an UPDATE query UPDATE your_table SET owner = '$some_new_value' WHERE owner = '' LIMIT 1

The problem is not php, its a requirement of the HTTP protocol. Headers must be output before any content is sent (white-space is content as far as the protocol is concerned.) The error is not unnecessary. It tells you two things - 1) The session_start failed, so none of your $_SESSION variables will work, 2) That you are outputting something before a header and where it is being output at so that you can find it and eliminate it.

mysql_error gives the textual error message.

According to the error messages, the session_start statement is on line 4 in your file and you have something being sent as output on or before line 3. What's in your file before the <?php tag?

Also, insert queries don't have where clauses.

There can be a dozen different reasons code does not work when moving between servers. What have you done to pin down exactly at what point your code and data are doing what you expect and at what point they are not? I can guarantee that the problem lies somewhere between those two points. If all you have done is to try your code and it doesn't work, all you have pinned down the problem to is somewhere in your code and that doesn't tell us anything that would allow us to help find the problem. We already know your code doesn't work, since you are posting in a programming help forum. Do you have any error checking and error reporting logic in your code to get it to tell you if your query is even executing without errors? Are you sure your code where the query is at is being executed? What sort of symptom or error are you getting?

The % are wild-cards that are only used in LIKE statements (and in the access control privilege settings.) Using % in an = comparison would require that the data contain % characters for the comparison to return a true value.

If you are trying to find if there are any new/unread messages, your query would need to be - $query = "SELECT COUNT(*) as num_new FROM inbox WHERE status = 0 AND to_mid = {$_SESSION['id']}"; You would then execute that $query statement, fetch the row from the result set, and access the $row['num_new'] value to get the count of the number of new/unread messages for the current user id.

I believe there is a word-form issue in awjudd's post. He means - your application should have one database that holds all the data for your application. Each table within your database would hold all the same meaning data for that table, regardless of the date, so that it would be possible to easily access any/all of the same meaning data. You would have a date (or datetime) column in any table that holds the relevant date (or datetime) of the data in the row. You should not be dynamically adding databases or tables within a database. That creates a data management nightmare. To prevent query errors, you must perform a query to check if a database/table exists, before you can query for the actual data or you must hard code some data that lists the database/tables that do exist and then have logic to check if a query is not trying to access data outside of the valid range. Database tables with 10+ million rows are not a problem. In fact, the most common use of an unsigned integer as a primary key would allow for 4,294,967,295 rows in one table.

The current problem is your query on line 34 is failing. You would need to use the mysql_error() logic for that query to find out why it is failing.

That error occurs when the variable being put into the mysql_query() statement is empty/doesn't exist. You need to pin down exactly which query is failing on your combined page. For us to help with a problem on your combined page, you would need to post all the code needed to reproduce that combined page.