gizmola

I see no problem with your SQL.

It's mainly a convenience as variables are easier to work with. The point of the $config is to have one variable that holds all your configuration data. This is often combined with a registry object that can be used to create various resource variables. Since the registry would be a singleton, you don't have to pass variables to every function -- you implement a static method call that returns the registry, so it can be retrieved anywhere it's needed via something like: $registry = Registry::getRegistry(); I don't plan to introduce all that complexity in this thread however.

At this point you want to be bootstrapping your configuration info in your index.php. The require_once function you're going to use require paths to the files on the file system. At this point you know you need a $basepath variable, a $configpath variable and a $pagepath variable. You should do this all in your $config. You will require_once() your $config at the top of your index.php. It should be clear how to specify that via a relative path. Then you want to call a function that starts your session. You can just have this function in your index.php. It's not that important that it be a function in this case, but it's good practice to put a discrete piece of functionality into a functionality for organization purposes. Get that working and add a little code in there to test it out -- make a session variable and increment it each time you visit the index.php and display the session variable. The next task you'll need is to grab any $_GET parameters and display them. So you can start to see something, create

Yes exactly. Then you can create other variables like $configpath and $controllerpath etc. off the $base.

Yes you got it. You'll include this near the top of your controller (index.php) and that way you have access to everything you need. In the example above, let's say you wanted to call mysql_connect() then you might have code like: $conn = mysql_connect($config['database']['host'], $config['database']['user'].... etc

Yes exactly. What most frameworks do is provide a config class. I would just make an array for now, where you can have a key for each different section of configuration you will need. So you might start with something like this: $config = array{ 'database' => array( 'host' => 'localhost', 'user' => 'dbusername', 'password' => 'dbpw', ), 'email' => array( 'admin' => 'me@mysite.com', ) etc. ); One thing i forgot to mention is that you will probably want to setup your paths. There are a few techniques for this but an often used one is to make either variables or constants derived from the DIRNAME of __FILE__. Based on where you put the file that contains this code, you will be able to know relatively where the other files will be. Probably you want this script to be in config.

Hey guys this is really getting off topic. Let's move the discussion forward ... what is a better sport to watch, Ice Hockey or Women's professional tennis?

Currently your js has a syntax error you need to fix.

Ok glad we cleared that up. There is no reason for you to have mulitple "mysql user accounts" . Your application is the one connecting to mysql, not the users themselves. The concept of individual users should be something that exists in your application. Typically people implement a user table. Mysql is built for concurrent access. There is nothing special you need to do. Someone editing a row does not stop another person from reading information or inserting new rows. With that said, I don't want to write a novel here, but I highly recommend that you use the innodb engine type for your tables. If you did not start that way it is not a major problem -- you can alter the tables to change them to innodb using the ALTER TABLE command. For a system dealing with finance you will inevitably want to have transactions and mysql with the default isam engine does not support transactions. Also innodb has constraints and implements row level locking, whereas myisam only can do table locking. That does not mean that you will have contention problems because the way the table locks in myisam work is extremely fast. However in general innodb performs better and has a lot of features that are considered essential in most other RDBMS's. In your code you can close your mysql connections if you want to, and it's good practice to have clean code, but it's not necessary as php has page scope and the connections will be garbage collected when the script has executed. Unlike many other rdbms's the mysql connection process is extremely lightweight so making and closing connections in every script is not a performance concern.

You need to figure out what type of basic structure your framework is going to support. The most used pattern is MVC. You could take some time to look into that, but I can suggest a very simple plan which is to start with the concept of a controller. The controller in your case will be the index.php. So all scripts will be run through the index.php using this simple idea: index.php?page=pagename You will be able to have additional page specific parameters when needed index.php?page=articles&title=i_am_a_php_guru_1 And one of your first "pages" or "actions" is going to be "login" index.php?page=login By using this scheme you now have some clarity on where things need to go. So you can begin to create functions and pieces of code that do individual things and for the framework specific code. What I'd suggest in using this scheme is that you have a directory beneath the project root that you name /pages and you will put all your page/action scripts there. Have a /config directory for configuration files you'll make and load in your index.php The order of things you'll need to do in the index.php -read in the configuration -load the session Read this if you haven't, because sessions are what you're going to use to provide the mechanics of your login. sessions

Have you looked at the net panel in firebug when the page is loading and checked out what is happening? Are you seeing jquery loading?

Ahh, that is a bad break. So the guide is from MySQL themselves? I would take another crack at them. If you want to PM me details on this, and you can't get any satisfaction on it, I'll see if there's anything I can do to help in dealing with them.

Why would you be offering to buy a CD when the one you bought was broken? Did you contact amazon -- perhaps they will send you an entire new book.

If you mean the definition, you use describe: DESCRIBE table setcolumn

There's a great tool for helping test and learn regex http://weitz.de/regex-coach/ This site does a fantastic job covering the subject: http://www.regular-expressions.info/

Technically you do not need to have a primary key, but not having one in most cases is a bad idea. When you define a PK, you are also creating a unique index for the pk, that will be used in queries and joins.

No problem with having an active account that is not activated. Typically you will let someone login who has an "active" but unactivated account and display them a message that explains they need to activate it, look for the activation email, yada yada, and provides them a way to request another activation email be sent. People who have a status

Let's see your code. You need to explain what "doesn't work" means.

Here is what you want to do rather than specifying the protocol. It needs to be done before your $(document).ready of course, which is probably why yours is not working:

Contact the publisher and see if there's a way you can get a replacement.

if the table can have more than one row with the same model_id, then model_id can not be the primary key by itself. The primary key, whether it be one column or more, has to be able to be used to uniquely identify any one row in the table.

In stored procs, the results of a regular select are returned to the client.

The char(32) will work for md5() so that's what you'll use. For activation add a column named `activated` tinyint default 0. You will set it to 1 when activated. You will probably also want some sort of activation mechanism. What a lot of people do is add column like: `activationkey` char(32) default NULL And you can generate a seperate md5() hash of something and then you mail that to them filled in as a get parameter for an activation url you implement. That script simply flips the active column from 0 to 1. But before we get too far into the weeds, finish up the table design. When you're sure you have what you want you can move on. You should consider Drummin's suggestion of adding a status (also use a tinyint default 1. A scheme that could work pretty well might be: status -------- -2 = Banned -1 = Inactive (maybe you'll allow users to deactivate their account or you'll deactivate old accounts) 1 = Active This scheme makes it easy to check that the status > 0 and you can add new status that are either postive (they should login) or negative (they shouldn't) and your basic check won't break or require modification.

That error is telling you you have more than one row with '17' in the model_id column. So mysql will not let you declare that to be the pk because pk's must uniquely identify a row.

If you google you can find out more. Facebook is a big user of memcached. They also have compiler project that takes their PHP code and compiles it into binaries. There are a number of books on the topic including this one by the lead dev from flickr: http://www.amazon.com/Building-Scalable-Web-Sites-Henderson/dp/0596102356