Muddy_Funster

again, without knowing what each "thing" is it's not really possible to give an accurate example. A generic example would somthing along the lines of foreach($topLevelArray as $subArray){ if(!isset($subArray['arrayKeyToCheck'] || empty($subArray['arrayKeyToCheck'])){ runDataInsertFunction($subArray); } elseif(($subArray['nextKeyToCheck'] < $valueToCheckAgainst) && ($subArray['lastKeyToCheck'] > $valueToCheckAgainst)){ sendEmailFunction($subArray); } else{ runErrorFunction($errorDetails); } } This is just a simplified version that is half way between your psudo-code and the actual code you would use and is assuming a multi-dimensional array as the initial $topLevelArray.

You're welcome.

It's not just the php: ok, none of your variables make any sense, but neither do your database column names, and neither do your html form element names (with the exception of Input). You need to use relevent and descriptive names for things, otherwise the code meens nothing to anyone else and will be impossible for even you to maintain. As ChristianF said, it's not all that bad, and I admit I was a bit harsh with my last post, but this is a way of coding you need to stay clear of. When you say "the first field" do you meen the entire first record or just the first entry in the cl column?

it has been padded with white space somwhere along the line. try using the trim() function to either clean up the database content or the variables

could you var_dump($list) and var_dump($dname) please?

Don't use dreamweaver for coding (as in : at all / ever). Don't use SELECT * either. Are you honestly saying that every entry in your client table has the same client_id??

have you checked the manual pages on foreach()? Without some contextual information about what each of these statements and parameters are no one can give you an accurate translation of your psudo-code. Also, if you are thinking about getting into programming, I suggest you have a look here http://en.wikipedia.org/wiki/CamelCase

Ok, is there an error or is there a warning (or perhaps a notice)? These are different things. Rather than suppression you should properly code to catch issues like that by checking the if(!isset(...)). Using !isset() will not throw an error/warning/notice if the variable has not been declared. To be fair, you really shouldn't touch error supression ar all unless you are already managing errrors on your own with custom code. We will need you to post up all the relevent code, including the form, and also a source view of the page once it's rendered in the browser. What you have in the OP is not enough for us to work with.

Taku, would you be willing to submit that code as an example of "worst practices: how not to code in any language ever"?

why are you constantly supressing the lines that have $dev on them?

I suggest you get a book on JQuery and AJAX. It's quite an expansive topic with multiple ways to solve most given problems. What works well for ChristianF would likely not make much sense to you from simply looking at the code and this will not help you get your head around AJAX calls and the power that they can provide. I was given an old book on AJAX and PHP from 2007 and it was about 235 pages(ish), without touching on JQuery. It's not a subject you will learn from a single, simple code example. Although ChristianF may just write the code for you, that normaly incurrs a charge.

You are very welcome. Just to say, I used the $row[$value] rather than the $row->$value because I used mysql_fetch_array() rather than the mysql_fetch_object() that was in your original code. mysql_fetch_array() fetches the dataset as an array, rather than an object, so the use of object syntax such as $obj->param wouldn't work. For the most part I would suggest avoiding mysql_fetch_object(). It's not that there is anything at all wrong with using it, it just tends to over complicate things in my opinion. There are some cases when it is the better way to go, but for a small and shallow dataset, such as the one in your example, it's not really giving you any benifits. Good luck, and I hope the wounds heal without scaring (be thankfull you weren't using select * as well )

no no no, your calling a query inside a loop. If I had a ruller and could reach your knuckles you'de be bleeding just now. Looping through the array is not what you want to do. You want to use the PHP function implode(). This lets you take an array and flatten it into a string, using the delimiter of your choice. So... $lookup = array('id','last_name','email'); $value = implode(", ", $lookup); $query = "SELECT ($value) FROM user WHERE id = $id LIMIT 1"; $result = mysql_query($query) or die("Well that didn't work...and here's why : <br />".mysql_error()); while($row=mysql_fetch_array($result){ foreach ($lookup as $key => $value){ echo "{$row[$value]} : $value "; } } That's untested but removes the query from inside the loop, reducing the transactions on the database.

you can pretend a page is an exel file by manipulating the header. I don't know how it will translate an html table but using header("Content-type: application/x-msdownload"); header("Content-Disposition: attachment; filename=yourFileName.xls"); header("Pragma: no-cache"); header("Expires: 0"); will force the browser to treat the page as an exel file download.

what?

It seems likely that the controller.class.php hasn't got visibility of the template.class.php. either the template class file isn't being included in the preloader, or the script that you are loading it from could be loading it in the wrong order.

The difference is that you are in control of the scope of the second decleration and not the first. You should always explicitly define the scope of your methods and variables rather than relying on the PHP systems defaults. If the default behaviour of PHP's scope definition changes in the future then the that will have an effect on anything you have not explicitly defined, and most likely break your classes. As far as I remember PHP only allows for the omision of the scope deffinition (public, private or protected) purely for a legacy compatability. No new code should be writen without the use of one of them.

show me what php you have tried so far and we'll take it from there

You found the problem, but do you know what the problem was? that which I echoed out was different to what you did, I'm not in the habbit of re-writing things for the fun of it or to pass the time. The point I was making was that you should be checking the content of the variable at each change. Why did $date work when $date[$i] did not. What was $date[$i] if it wasn't what you expected it to be? These are the key questions you need to be able to answer.

erm...that depends on your deffinition of "close". Your using the session array in a non-depreciated way, but you are nopt using isset() properly, and you are over complicating your variable handling.

I've updated your fidle using basic debuging 101, run it now and see if you can find the issue

Then I'm afraid, the only option I can see is, you will have to present the page as it is - and tell your boss that if he's going to insist on being a total fud burgler this is what he gets.

You're boss told you to use frames and yet the project is for school? I'm a bit confused here. Please explain what's going on here.

I reckon seeing a view source of the form page could be helpfull, just to see what's in those hidden fields. also, you have missed the / out of the closing tag for the textarea in the code you posted here. Edt: Without the loop this is what the form source looks like on my machine: <tr> <td align="[url=""]center[/url]"> <input type="[url=""]hidden[/url]" name="[url=""]wod_date[][/url]" value="[url=""]2013-01-10[/url]"> Jan 10th 2013 </td> <td> <textarea name="[url=""]wod_note[][/url]" style="[url=""]resize:none;[/url]" maxlength="[url=""]255[/url]" cols="[url=""]25[/url]" rows="[url=""]3[/url]"> </textarea> </td> <td align="[url=""]center[/url]"> <input type="[url=""]hidden[/url]" name="[url=""]wod_admin[/url]" value="[url=""]10845[/url]">10845 </td> </tr> 2nd Edt - ignore the URL's all through that, thatis the damn code formating on this board again

I'm not really getting the logic behind that statement.