roopurt18

Where did you have to put that?

You only need one house.php file that has a URL parameter: /house.php?house=1 or /house.php?house=2. Read up on GET (or $_GET) to see more examples. As for your SQL statement, what does your table structure look like?

The documentation for array_multisort() has an example of such an operation.

I would think that if you had enough static content to warrant static content servers, you'd invest the time and money in some sort of managed file share solution that hides the details of which server the file is actually on and still allows you to access it off of a regular old file path. Does such a thing not exist?

Are you on a shared computer?

Your web browser will often do this.

I'm going to chime in and agree with thorpe on the file system. NTFS is horrible. You have fragmentation problems that I've never seen occur in common file systems used by Linux. I don't know what it is about the internals, but file operations like searching are incredibly slow in comparison. Couple the NTFS file system with the absolute shit MS Search utility and a simple task like "Which files are consuming all my hard drive space?" becomes impossible to answer in a timely fashion.

Your wtaken column is redundant as you can always calculate the week of the year based off your dtaken column. This might work: <?php $start_tm = date( 'Y-m-d H:i:s', strtotime( '6/1/2009' ) ); $end_tm = date( 'Y-m-d H:i:s', strtotime( '1/1/2010' ) ); $select_stmt = " SELECT r.`id`, r.`emp_num`, r.`ans1`, r.`dtaken`, r.`wtaken` FROM `responses` AS `r` INNER JOIN ( SELECT DATE_FORMAT( `dtaken`, '%U' ) AS `week_of_year`, COUNT(*) AS `number_of_responses`, AVG( ans1 ) AS `average_rating` FROM `responses` WHERE `dtaken` BETWEEN '{$start_tm}' AND '{$end_tm}' GROUP BY DATE_FORMAT( `dtaken`, '%U' ) ) AS `s` ON DATE_FORMAT( r.`dtaken`, '%U' )=s.`week_of_year` WHERE r.`dtaken` BETWEEN '{$start_tm}' AND '{$end_tm}' "; $q = mysql_query( $select_stmt ); if( ! $q ) throw new Exception( 'Select error: ' . mysql_error() ); ?>

You would be much better off if you did the following: 1) Called set_error_handler() and created your own error handling function that logs to a file, errors.txt or errors.log. I find it handy to keep a static array within this function and ignore duplicate error messages. 2) Create a top level exception handler that does the following: i) Generates a unique ID based off the timestamp and some other criteria ii) Logs the exception message and unique ID to errors.txt (or errors.log) with the additional text "FATAL EXCEPTION" so that you know it was an exception. iii) Display a generic message to the user: "Your request has resulted in an internal error. Contact technical support with the following error ID $erroridgoeshere or try again." Then when you write code, instead of using or die() you can just throw Exceptions. When testing your application if you see your generic error screen, you can check the errors.txt for the related ID and see how / why your code failed. Additionally you don't have to remember to remove or comment out potentially dangerous or die() statements. Your exception handling mechanism can actually just be left in place. Your users won't be presented with information they can abuse and you'll be left with useful logging you can track on going problems with (such as "Is my database connection constantly failing").

I don't know of any tool or script that does this, so my suggestion would be to write a small program that queries information schema and does this. Keeping the database schema consistent between multiple environments can be a pain in the neck. For a long time I had a $version.sql file that accompanied each version and performed any database structure changes. This eventually presented me with two problems: 1) As program versions increase you will be left with many SQL script files. Without an automated update process, updating an installation from version 2.0.5 to 2.0.37 can become a huge hassle. 2) Sometimes it is convenient to run program code in-between operations on the database structure. In this case, the update process turns into: + Run $version.a.sql + Run update program + Run $version.b.sql + Rinse and repeat as necessary The whole system quickly becomes unmanageable. I recently began experimenting with solutions to this problem and my most recent incarnation is to do this: 1) Add a table to the database named application with a column db_version. This table should only ever have one row (enforce with triggers if possible) and essentially contains meta-information about the application. 2) application.db_version can be numeric or text, whichever you prefer. Now create a class: <?php class DatabaseUpdater { /** * Call this function to update the database. If the database is in need of updates, they will be applied. * Otherwise nothing occurs. * * @param bool $test_only */ public function Update( $test_only = true ) { $db = new PDO(); // create your database handle, tell it to throw exceptions echo 'Applying database updates...' . "\n"; if( $test_only ) { echo "TESTING ONLY -- NOTHING COMMITTED\n"; } try { $db->beginTransaction(); $t = $this->apply_1( $test_only, $db ); $t = $t && $this->apply_2( $test_only, $db ); $t = $t && $this->apply_3( $test_only, $db ); } catch( Exception $ex ) { $t = false; } try { if( $test_only === false && $t === true ) { echo "Attempting commit..."; $t = $db->commit(); echo "yes\n"; }else{ $db->rollBack(); } } catch( Exception $ex ) { echo "no\n"; } echo 'Database updates are a ' . ($t ? 'SUCCESS' : 'FAILURE') . "\n"; if( $test_only ) { echo "Run again with \$test_only = false to apply the updates.\n"; } } /** * Applies version 1 of database. * * @param bool $test_only * @return bool */ private function apply_1( $test_only, PDO $db ) { echo "Apply version 1..."; try { $q = $db->query( "select count(*) as n from information_schema.tables where table_name='application'" ); if( ! $q ) throw new Excpetion( "can't count" ); $row = $q->fetchObject(); if( ! $row ) throw new Exception( "no row" ); if( ! isset( $row->n ) ) throw new Exception( "no count" ); if( ((int)$row->n) === 1 ) echo "yes\n"; else throw new Exception( "application exists already" ); } catch( Exception $ex ) { echo "no\n"; return false; } try { ob_start(); ?> -- This is our sql upgrade script create table application ( db_version integer ); create table users ( username varchar( 32 ), password varchar( 40 ) ); -- create a trigger on application that allows only one row to exist -- now insert the database version into application insert into application( db_version ) values ( 1 ); <?php $sql = ob_get_clean(); $db->query( $sql ); } catch( Exception $ex ) { return false; } return true; } /** * Applies version 2 of database. * * @param bool $test_only * @return bool */ private function apply_2( $test_only, PDO $db ) { echo "Apply version 2..."; try { $q = $db->query( "select count(*) as n from application where db_version=1" ); if( ! $q ) throw new Excpetion( "can't count" ); $row = $q->fetchObject(); if( ! $row ) throw new Exception( "no row" ); if( ! isset( $row->n ) ) throw new Exception( "no count" ); if( ((int)$row->n) === 1 ) echo "yes\n"; else throw new Exception( "wrong db version" ); } catch( Exception $ex ) { echo "no\n"; return false; } try { ob_start(); ?> -- This is our sql upgrade script alter table users add column first_name varchar( 36 ); alter table users add column last_name varchar( 36 ); update application set db_version=2 where 1=1; <?php $sql = ob_get_clean(); $db->query( $sql ); } catch( Exception $ex ) { return false; } return true; } /** * Applies version 3 of database. * * @param bool $test_only * @return bool */ private function apply_3( $test_only, PDO $db ) { echo "Apply version 3..."; try { $q = $db->query( "select count(*) as n from application where db_version=2" ); if( ! $q ) throw new Excpetion( "can't count" ); $row = $q->fetchObject(); if( ! $row ) throw new Exception( "no row" ); if( ! isset( $row->n ) ) throw new Exception( "no count" ); if( ((int)$row->n) === 1 ) echo "yes\n"; else throw new Exception( "wrong db version" ); } catch( Exception $ex ) { echo "no\n"; return false; } try { ob_start(); ?> -- Update the db in some manner update application set db_version=3 where 1=1; <?php $sql = ob_get_clean(); $db->query( $sql ); } catch( Exception $ex ) { return false; } return true; } } ?> Quick note: This is not my real code. I typed it up real quick so don't copy and paste it expecting it to work. Use it as a template for the idea I'm talking about. The purpose of this class is to have a single public method Update() that will call many private methods actually responsible for updating the database schema: apply_1(), apply_2(), apply_3(), etc. The main update method can be run in test_only or commit mode. In either case, a database handle is created and a transaction is opened. Then each apply_*() method is called in sequential order. Each individual method is responsible for determining if it should run. The first method will check if the application table exists; if it does not then it assumes an empty database and will create the initial schema. As the last statement the application table should be updated with the current version of the database. Each successive apply_*() method is intended to run off a specific value in application.db_version. If application.db_version() is not the correct value, then the apply_*() method ends early and does nothing. Finally, if all apply_*() methods returned successfully and the run mode is commit, the transaction is committed. Otherwise the transaction is rolled back and nothing occurs to the database. In this way, you can plop this code into any environment and call a single method to update your database to the correct working version. There's no more SQL script files to manage and apply manually. You can easily inject PHP code into the update process. All in all it's much less error prone and more manageable, for me at least. (edit) I expect some day I may run into an issue with the number of statements allowed within a single transaction.

This occurs a lot in programming. Also, there is a tutorial somewhere from the main page about why or die() is bad. I suggest you read it before you use it all over the place.

The FROM clause expects a table name; you're giving it a column name. Thus the error "table does not exist."

You'll have to find a way show your support for FireFox without igniting memories of the early days of the web, when every site was "designed" for one browser and version only.

"Designed for FireFox." Is it 1996 again?

Multiple monitors can be a real pain in the neck if you're not careful.

If you only want to know that elements of $tag exist in $line and don't actually care about the character position, you can do something like: <?php $line_has_tags = count( array_intersect( $tag, array_unique( explode( ' ', $line ) ) ) ) > 0; ?>

<?php $table_name = array_key_exists( 'tablename', $_GET ) ? $_GET['tablename'] : ''; if( ! preg_match( '/^[a-zA-Z0-9_]+$/', $table_name ) ) throw new Exception( '$table_name is invalid: ' . var_export( $table_name, true ) ); $select_stmt = " SELECT * FROM `{$table_name}` WHERE 1=1 "; ?>

Since when?

I wrote those a while ago. Hopefully they are still useful.

You will want to read up on variable scope. A global variable $connection is different than the variable $connection defined in a function. Php doesn't automatically move to global scope when performing variable name resolution, although some languages do.

$result = mysql_query("SELECT * FROM positions ORDER BY abbr ASC", $connection); $connection is undefined.

By creating a proper index on the table, it'll find the records for a single user just as fast as if they were in a table all their own. You should really start understanding databases before you start designing database applications or you're going to create quite a mess for someone else to maintain.

Just in case you are new to online communities as well, here's a tip that will go a long way. Members of technical communities, such as computer-related forums, value proper use of language highly. You will find that if you take the time to use proper capitalization and punctuation people will be more willing to assist you. If English is not your native language, then just add a simple note your signature, something like Forgive my English, I'm a non-native speaker. will prevent you having to say so in every post you make.

If users can potentially be adding the same resources to their favorites, then what you have is called a many-to-many relationship. In many-to-many relationships, you typically have two tables. In your case, users and favorites. users id, name, password, ... favorites id, url, img, whatever_is_appropriate_to_describe_a_favorite Then you have a third table that joins the two together: users_to_favorites user_id, favorite_id

I usually have a table of uploaded files: uploaded_files id, orig_name, user_id 1, 123.jpg, 4 2, 123.jpg, 5 The files themselves are stored on disk at some path, i.e: /home/webapp/uploaded And the file names are that of the primary key in the database: /home/webapp/uploaded/1 /home/webapp/uploaded/2 This accomplishes a few goals: 1) Since primary keys are guaranteed to be unique, so are the file names. 2) Since I've kept the original file name in the database, I can always present the original name to the user and they will be none the wiser.