mac_gyver

one of the reasons for the yyyy-mm-dd format for a DATE data type is because that format is required in order to compare dates by magnitude. other reasons for using a DATE data type include being able to use the mysql DATE functions on the value, the most efficient data storage, and the quickest queries. you need to store your dates as a DATE data type, with that format. to insert dates that have a different format into a DATE data type, you need to reformat them. you can either do this in your php code or you can use the mysql STR_TO_DATE() function in your query.

dynamically adding form fields is typically used when adding empty fields for data entry, such as adding a set of fields to enter the data for each additional person in a family or adding a new car to your insurance coverage... it is not used to reveal existing information, as that just adds extra clicks to the process and makes for a bad user experience on your site. if what you are wanting to do is make the select/option menu contain all the possible products (less ones that have already been picked up to that point), that's not what your code is currently doing and still makes for a 'click happy' bad user experience on your site. if what you are wanting to do is provide a way of selecting among all your products, see my reply in your other thread.

making a select/option menu that has only one choice, repeated for each product, makes no sense. what is the purpose of the select/option menu in your code? you would typically display all available products at once, ordered by category and/or name, or if you have a large number of products, provide a search box, category selection menu/links, or use pagination to limit what's being displayed at one time. the one-time non-product information for the order would normally be entered as a separate step, not as part of the product selection. you should not store the three prices in separate columns in your products table. multiple prices should be stored in another table, one row for each price, tied back to the products table using the product id. you can then store any number of prices for any product. when you JOIN the two tables to display the information, you will only get a row in the result set where there is a price. your code to produce the (three) radio buttons would simply loop over however many rows the JOINed query returns and produce that number or radio buttons. any time you find yourself repeating code, that only differs in the value it uses (such as your 3 radio button logic), it's a sign that you should be using a loop of some kind rather than writing out the code n number of times for each possible input value. before you move up to using jquery/ajax, you need to be able to produce the client side and server side code that accomplishes your task, since you will still need all of that client and server code when using jquery/ajax. jquery/ajax isn't required to make certain types of pages work. they only allow you to dynamically do things in the client without refreshing the page. without using them only means that when you perform an action in the client, the resulting output completely comes from the server.

the following is equivalent, without the extra $myarray that's causing all the data to be stacked together, to what you are showing - while ($row = $result->fetch_assoc()) { file_put_contents("message/{$row['id']}.json", json_encode($row)); }

yes, your errors are due to the debugger. php code debuggers generally work by adding a layer of output buffing to send the debugging information to their client module. you should generally only use a debugger to debug why your code isn't doing what you expect (that's why they are called debuggers), not as the primary method of running your code.

php include/require statements, unless you specify the syntax for a url (protocol, domain, path, file - i.e. http://your_domain/your_path/your_file.php), operate on files through the file system, where url get parameters - ?some_name=some_value have no meaning. however, you would in general not want to use a url, because it is slow (your web server makes a http request back to your own web server), you only get the OUTPUT from your file, not the actual php code, and the two php settings that are required for a url to work are turned off by default due to the security problem of this allowing unvalidated external values being used to specify included files to allow a hacker to include their remote code onto your server and run it on your server. if your goal is to retrieve some information based on an id and make that information available to the 'calling' code, you would write a function that accepts the id as a parameter and returns the data to the calling program.

because you haven't posted any actual output from your code, there's a chance that the error is in your interpretation of the result. also, unix timestamps are not reliable, since an actual conversion between different number systems is required to use them. the following is from mysql's own documentation for it's unix timestamp based functions - why not just store a mysql DATETIME value?

to fix your debatable design, you don't need to run the query that doesn't work/times out. you need to select all the rows from the badly designed table, that has the multiple string values stored in the single column, split up those values, get or assign an auto-increment integer id key for each unique string value, then insert row(s), one for each existing row and each original split values, into a new table, with the id corresponding to the string and the id of whatever you are relating that information too. the resulting table should only have integer id values in it. for example, if you have a row in your existing table with only one of these string values stored in the offending column, you would end up inserting one row in the new table. if you have a row in your existing table with three of these string values stored in the single column, you would end up inserting three rows in the new table. once you get finished with this deconstruction/reconstruction process, you would use this new table in JOINed queries to relate, using exact value, integer, matches, the source data in the parent tables. then, by using correct indexes on the tables, you can easily and quickly query tables that contain several millions of rows.

in real life applications, data is not actually deleted. if you insert a row into a table and assign it an id (identifier), that row is never deleted, so that any data that uses that id will always be valid. if you want to make a piece of data unavailable at some point, you would have a status column that controls if it can be chosen. yes, you would have a price table that contains the product_id, customer type, and since the price for anything can change over time, a start date and end data that the stored price is applicable.

the file of code in post #5 isn't running any code. that's just the class definition. browsing to that file WON'T produce any output. you would need to include/autoload that file, make an instance of that class, and reference the class methods/properties of that class.

your post above shows - Posted Today, 08:02 AM for me. i also tried a different browser and the result is the same, 20 minutes behind. my profile settings for time zone is correct. i'll set my time zone to something else, then back to see if it corrects the issue. just more ipb crap. edit: changed my time zone to central and back to mountain and even tried the variations of the DST check-boxes, the hour changed as expected, but the minutes are behind. guessing something in the back-end settings under my username have 'adjusted' the timezone by 20 minutes.

the time being shown for posts and the Time Now: being shown at the bottom of pages is currently 19-20 minutes behind real time. in my time zone, it's currently 7:37 am. the time at the bottom of the page is 7:18 am.

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.

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.