mac_gyver

when the database connection fails and you run a statement that uses the connection variable, like - foreach ($connect->query($sql) as $row) you get a fatal runtime error that halts code execution at that statement. when something fails, you need to take an appropriate action, which would include not running any code that's dependent on whatever failed. why are you setting error_reporting to zero in the catch{} block of code? for development, you would want to report and display all errors, not hide them and on a live server you would want to report all errors, but log them rather than display them.

to get php to show fatal parse errors in your main file, you must set the error_reporting and display_errors settings in the php.ini on your development system. you would find the php.ini that php is using (see the Loaded Configuration File value in the output from a phpinfo() statement), then find and change the error_reporting and display_errors lines in it, to be error_reporting = E_ALL and display_errors = On stop and start your web server to get any changes made to the master php.ini to take effect. once you put these settings in the php.ini, you don't need to put them into your .php files.

only checked check-boxes are submitted and you have no relationship between the check-box and the text input field holding the updated date. you can see this is you examine the submitted post data. add the following debugging line of code to see what is actually being submitted - echo '<pre>',print_r($_POST,true),'</pre>'; your database table should have an autoincrement id (identifier) column. i recommend that you use the id as the form field array index for both the check-box and the text input field. this will serve to tie the check-box to it's corresponding text input field.

if the html of the form is actually present (have you checked the 'view source' of the page in the browser type where it doesn't work), browser problems like this are usually due to invalid markup/css that some browsers ignore the problems in, but other's don't. your page has 70 makeup errors and 67 warnings - http://validator.w3.org/check?uri=compareandchoose.com.au%2Fhome_loans&charset=%28detect+automatically%29&doctype=Inline&group=0 most of the errors are because the html comments are broken, which means that some browsers will see part of the html as being part of the comment. if you are dynamically producing these pages, why do you even have html comments in it? you should have php comments in the php code.

similar to my reply in your other thread, if you are at the point of trying to make an installer script, you should be dynamically producing any form and dynamically processing the form data, rather than writing out the specific html/php code for each value for each step. you would do this by having the form fields and validation steps for each field/type defined in a data structure somewhere (a database table or an array.) the data structure would contain the dynamic information for each field in each step, such as the form field name, the label for the form field, the type of form field, any lists of choices (select/checkbox/radio), and what validation step(s) to 'call' (using variable functions) for each field.

if you are at the point of trying to make an install script, all your code manipulating the values should be general purpose, rather than hard-coded with specific variable/defined constant names. if you are using variables, use an array ($config['db_host']). if you are using defined constants, use a prefix on the names (CONFIG_DB_HOST) so that you can distinguish them from any other defined constants you have in your code. the only thing in your config file should be the settings. there should be no functional code, such as the database connection. then, at the point of saving the values, why not just loop over the array/prefixed named defined constants and write out the php code containing the current values?

we actually know what you are trying to do, what we need to know is where you are stuck at when you tried to do it, because the purpose of programming help forums are not to write complete working code for you or to think out the details of each step that you need to do, we are here to help when you get stuck on something, after you have made an attempt at doing it. have you defined the user steps for the confirm-order process? what information do you have and what will be displayed at each step, and what new information do you need from each step? seems that if the visitor is viewing the contents of the cart and are ready to finalize the order, wouldn't the next step be to collect any new customer information or confirm existing customer information, such as ship/deliver address (it could be different for each order), billing name/address (if they use a different payment method, this can be different for each order), ... then create a record in an 'orders' table for this customer on the date and time in question that would assign an order_id, that you would then use to relate and store the contents of the cart in an 'order_items' table? once you have done this, you would have a 'pay' form/button that would submit/take them to the paypal site for the actual payment process. the code for the particular step of inserting the data into the 'order_items' table, would in its simplest form, be to just loop over the contents of the cart, form and run the INSERT query with the order_id, the dish id, quantity, and if the price can vary, the price at the time of the order. for bonus points, you can form and run one efficient multi-value insert query, rather than running a query in a loop. the code you have for your session based cart needs to be simplified. you should create a $_SESSION['cart'] variable that is an array of the cart contents - $_SESSION['cart'][dish id] = quantity. this will eliminate all the substr() statements in the code. also, if the quantity of an item in the cart is/reaches zero, you should remove it from the cart. since the value stored in the cart is the quantity, you can just use php's array_filter() function to remove empty items from the cart.

the program logic that you are showing us makes no sense. the $event->nodeValue you are testing to come up with a color is the last value from the loop that's building the $events array. unless there's only one event or all the events are the same type, this won't result in the color matching the event type. regardless of your intent to loop or not, the value you test to come up with the color needs to be the $message value you are actually displaying. as to your current question, it's not clear if you want the first event or the first event of each type to be displayed. if you show an example of what the $events array looks like (and is the data from the rss feed in any particular order?) and what result you want based on that data, someone can tell you how to proceed. btw - your big long switch statement can be changed to a single program statement, assuming you switch (pun intended) to using a data driven design. see the following - // define the event type/name to color association (this would typically be stored in an included config file or in a database table) $color_mapper['Tornado Warning'] = 'rgba(255, 0, 0, 0.4)'; $color_mapper['Severe Thunderstorm Warning'] = 'rgba(255, 165, 0, 0.4)'; $color_mapper['Tornado Watch'] = 'rgba(255, 255, 0, 0.4)'; $color_mapper['Severe Thunderstorm Watch'] = 'rgba(219, 112, 147, 0.4)'; $color_mapper['Flash Flood Warning'] = 'rgba(139, 0, 0, 0.4)'; $color_mapper['Flood Warning'] = 'rgba(46, 139, 87, 0.4)'; $color_mapper['Flash Flood Watch'] = 'rgba(0, 255, 0, 0.4)'; $color_mapper['Flood Watch'] = 'rgba(46, 139, 87, 0.4)'; $color_mapper['Flood Advisory'] = 'rgba(0, 255, 127, 0.4)'; $color_mapper['Winter Storm Warning'] = 'rgba(255, 105, 180, 0.4)'; $color_mapper['Winter Storm Watch'] = 'rgba(70, 130, 180, 0.4)'; $color_mapper['Winter Weather Advisory'] = 'rgba(123, 104, 238, 0.4)'; $color_mapper['Special Weather Statement'] = 'rgba(255, 228, 181, 0.4)'; // at the point of mapping the event type/name to the color $alertColor = isset($color_mapper[$message]) ? $color_mapper[$message] : 'default value goes here...';

how many different databases? 5, 10, 100? there are no wild-card ALL database commands. to do this under program control would require that you get (from the schema data) or manually make a list of the databases with the tables you want to use as the source, then run a query for each source database that inserts into the destination database using an INSERT ... SELECT query. the mysql documentation for the INSERT ... SELECT query states it can be used to insert from multiple tables, which should include (untested) the ability to specify the database.table. assuming this will work for a UNION query, you could build the SELECT part of the INSERT ... SELECT to be a UNION query between all the database.tables that you need. to do this manually, the most efficient way i can think of would be to do .sql backups of all the source databases/tables that you need. then edit them so that the USE database commend points to the destination database. then simply import the data using the .sql files.

here is the sample code i posted above, with more details showing how it would control the building of the sections - // the business logic retrieves and stores the query results in an array $data. this serves as the input to this section of ocde if(empty($data)){ // there's no matching data, output an appropriate message here... } else { // there is data, start producing the output... $last_type = ''; // initialize this before the start of your loop that's display the data foreach($data as $row){ $strPrefix = substr($row["Prod_Type"], 0, 2); // output the product type heading each time it changes if($last_type != $strPrefix){ // the type changed if($last_type !=''){ // not the first section, close out any previous section here... // close the </div> for example } // start a new section here.... start the <div>, output any type image, .... $img = $types[$strPrefix]['img']; $alt = $types[$strPrefix]['alt']; echo "<img border='0' src='$img' alt='$alt'>"; $last_type = $strPrefix; // remember the new value } // output the data in each recored here.... } // you would close the last section here. whatever logic you have in the if($last_type !=''){ ... } above would be repeated or in a user written function that you call }

i recommend to just rewrite the presentation portion of the code to produce the output you want. the example code i posted above is actually more relevant to this than just the switch/case statement. by detecting the change in the RB, BH, RA type, the code can finish off any html for the previous section and start a new section. the code that displays the data just goes right after the if(){} logic i posted. i do have another general suggestion. separate the business logic from the presentation logic. the business logic contains the php code that figures out what to do on the page and retrieves any data that's need to display the page. the result of the business logic should just be php variables. all the database specific statements should be in the business logic (you would pre-retrieve database data and store it in an array) and there should be no html markup in the business logic. the presentation logic should contain no database specific code, since it will receive any data it needs in php variables. the presentation logic should contain all the html/css/javascript.

lol, spam in the spam filter thread ^^^. the GD based captcha works and should be use in the meantime. the complaint posts about the gd based captcha (from a member that had already written a couple of posts and never replied when asked a question about it and another member that never posted after the complaining post) were most likely from (the same) spammer(s) that just wanted an easier captcha.

we don't really know what you want to do different. can you specifically show an example of what part of the data and exactly how you want it to be done differently? also, this code has several problems that you should fix or change first. the two biggest ones are you should be using css to style everything, not inline styling, and your two nested while(){} loops, that are looping over the same data. by having these two nested loops, the first one is really only acting like an if() conditional statement to run the rest of the code. however, by having these nested loops, the first row of your result set is not being displayed, because the nested loop that's actually displaying the data, is fetching and starting at the second row in the result set. here's a general suggestion that will help reduce that huge switch/case statement, by eliminating the repeated logic and converting the design into a data driven one, rather than a hard-code logic one, and make it easier to change or fix the html markup, because any particular piece of markup will only exist once in the code. define the type information - // define the type information (typically this would be stored in a 'config.php' include file or retrieved from a database table) $types['BH'] = array('img'=>'bulkheads.jpg','alt'=>'Bulkheads'); $types['RB'] = array('img'=>'roofracks.jpg','alt'=>'Roof-Bars'); // ... repeat for all product types initialization, before the start of the while(){} loop - $last_type = ''; // initialize this before the start of your ONE while(){} loop that's display the data at the point where you want to output the product type image inside the loop - // output the product type image each time it changes while displaying the products if($last_type != $strPrefix){ // the type changed, output the image $img = $types[$strPrefix]['img']; $alt = $types[$strPrefix]['alt']; echo "<img border='0' src='$img' alt='$alt'></td></tr>"; // since this markup and code only exists once, if you are changing something about this section of code, you only have to make the change in one place echo $title; $last_type = $strPrefix; // remember the new value }

my supposition about different databases/connections was just one of the many possible things that could be causing the problem. i/we could probably list a dozen different possible things, but won't, because your setup could be doing something different than what i/we have in mind, and the actual problem could be the 13th item that no one thought of. you need to 'close the loop' by providing some investigation and feedback in order to narrow down the possibilities. solving this will require that you actually add the things that i mentioned to the code in order to pin down where and what is actually happening.

in the non-working case, you need to actually pin down what the code and data is doing, before you can even locate what needs to be fixed. you could for example have some broken html on the page for the id = 4 case that's causing the form to be invalid markup and it does not submit any data. the data itself may be invalid (or empty) and is resulting in query errors or a query that's not matching anything. your code could even be running twice for some reason and updating the data correctly, but is also updating it again back to the original values. you need to determine exactly what code is running, what values are being used by the code, and what is being returned from statements. 1. make sure that the code where the update queries are at is actually running. you should be forming the sql statements in a php variable (always), then just use that variable as input to the function that's running the query. you can then echo/log the contents of that variable for debugging purposes so that you will know that the queries are being ran and what data they actually contain. 2. make sure that all the queries are running without any errors. you should (always) test the returned value from a query for errors. an UPDATE query will return a false value when there is a query error. you can echo/log the mysql_error() information to let you know what the error is. and as a side note: you are using both the tep_db_query() and mysql_query() statements to perform queries. you could have a case where there are multiple database connections (even a default one set up by the php installation) and each of those methods of running a query could be operating on different databases. perhaps the database connections for one id = value are all using the same database and the code works, whereas for the other id = value, there are errors or missing data due to multiple database connections being used in the code.

that may be WHAT doesn't work, but exactly what about it doesn't work. are the values not displayed for picking, does the page just 'refresh' without apparently doing anything when the form is submitted, is the form data not present in the form processing code after the form was submitted, are there php errors, query errors, is the data just not updated in the database table, or is the data actually present in the database table but it is not having an affect when it's being used? in short, what symptom do you see in front of you, since we're are sitting there with you to see it, that leads you to believe 'it doesn't work'? there's very little backwardly incompatible differences between most of the php versions, and these things are generally obscure things that most code doesn't use (they are documented in the php.net documentation, appendix.) most problems like this are due to php configuration differences. in fact, only in the php5.4 version were a number of obsolete things finally removed (your use of $HTTP_GET_VARS for example aren't present as of php5.4+). edit: you also mentioned that the problem is associated with - vendors2_id = 16 works, vendors2_id = 4 does not work. the posted code only has vendors2_id hard coded as a 16. is the posted code the actual code that doesn't work and if not, why do you have different code that only differs in a value that's has hard coded that value rather than using one instance of the code and using a variable for the, well, variable value in it? if the code with a vendors2_id = 4 in it doesn't work, perhaps that's the code you need to post.

web servers can handle several 100's of requests per minute. just using the timer/ajax-request method will work for a casual chat system. you would want to make each request/response as brief as possible and make the server side code as efficient as possible, off loading as much formatting/processing onto the client as possible. the client side request, which should be a GET request btw, would include the id of the last message that has been displayed for that user. the server would just query for and retrieve any new messages with id's greater than that id. at a minimum, the message id column in the database table would be indexed. if there's no new messages, the server should return a simple status value to tell the client side code it doesn't need to do anything, perhaps just an empty json encoded array. if there are new messages, just return the raw message data, leave any formatting/display to the client side code. make sure that the database server has query caching turned on as well. when data in the database table hasn't changed, the same database query being made from multiple clients will return data from the cache rather than retrieving it from the database table. you can have 100's of clients all waiting for a new message and they will keep getting the result from the cache that there's no new messages until there actually is one that was stored into the database table, altering it, which causes the cache to be cleared so that it will then cache the new message(s) for the next series of update requests.

in the context of a monthly calendar, what do you want to display? displaying every open time slot for even one trainer (what if you have 20 trainers) would not be piratical. your monthly calendar could at best show a clickable 'event' on the days that have available bookings (and a non-clickable, 'full' listing for days that have no open time slots), either just one event total, if any of the selected/filtered trainers have an opening, or one event for each selected/filtered trainer that has an opening on that date, with a hoover/pop-open tool or a link that gives you a view/page that consists of the booking grid with the open time slots for the clicked on date. a monthly calender could be used for the appointment confirmation. you could display an 'event' on any days that have any un-confirmed appointment(s), for the currently logged in trainer. clicking on the 'event' would take that trainer to a grid of un-confirmed appointments that can then be reviewed and approved. assuming that a trainer would have the need to cancel an appointment, you would instead display an 'event' for all days that the trainer is available. clicking on any day would take the trainer to a grid that shows un-approved and approved appointments on that day with choices to approve/cancel each appointment.

there are existing resource availability/resource reservation scripts that probably do this in some fashion (likely for reserving/booking rooms, rather than a trainer, but the logic is the same.) you would need a table to hold the resource (trainer) availability schedule, all resources in stored in the same table, using a resource id to identify which rows are for each resource. for reoccurring schedules, you would need to store the definition of the schedule (Mike is available on Mondays-Friday from 8am-5pm) and evaluate it, storing the resulting dates and times in the availability schedule table, as needed (any query displaying data with a date higher than the latest stored date would evaluate the definition to populate dates up to at least the latest display date.) you would have a second table to hold resource reservations, with the resource id, the id of who is requesting the resource, the date, start time, end time, and a status. the status would indicate if the resource has been requested (someone selected a date/time slot, but it has not been confirmed) or booked (if the trainer has reviewed and confirmed the reservation.) any resource reservation with either of those status values would not be available for selection. if there is a preference for a particular resource or type of resource, you would get and apply a filter in the query that determines which resource id(s) you match in the resource schedule table and for just the date(s) you are trying to display. you would then join the rows from that table with the resource reservation table, using the resource id and date columns, to get the row(s) and therefore the start/end times the resource is (is not) available for selection. that should get you the data you need to display a grid of appointment slots that are (are not) available for selection.

besides listing what you want, do you have a specific programming question or a problem you need help with?

and, even if the session variable are being set as expected in the login() function, if the session start on that page has failed (there would be php errors), the login isn't actually working because the session variables will only exist as local variables and won't be propagated between pages. did you set the error_reporting/display_errors settings on each page or better yet those should be set in your php.ini on your development system so you don't need to remember to put them into code for debugging and remove them when you put your code onto a live server.

@Irate, please read and understand the thread before posting replies. it turns out the OP wants someone to be able to visit a page, but only by first visiting a preceding page.

your thread is about protecting included files against direct url requests. included files are support files that are incorporated into and used by a web page. included files should be accessed through the file system, not a url. you shouldn't have any intentional url links to an included file. if this doesn't address your question, please post an actual example showing what you are trying to do.

the issue with register_globals is you can set any php variable by setting the same name $_GET, $_POST, $_COOKIE variable. if someone knows your code in the included file is testing $including, they can simply add ?including=1 in the url when they request your included file and the if (!$including) statement will allow access to the file. there is/was a lot of open-source scripts that used this method, since the variable name was known by examining the script, and a lot of sites where taken over. fortunately, register_globals has finally been removed in php5.4. a better way is to use a defined constant instead of a variable (register_globals cannot supply a value for a defined constant.) an even better way, since it completely eliminates any processing time for the files, is to put the included files into a folder that cannot be directly accessed via url requests.

the suggestion to use a bootable linux cd wasn't to install linux, it was to boot to an environment where windows isn't running so that you can delete the file without it being locked by the windows operating system.