Leaderboard

Slightly different approach then. Store the category query results in an array. $stmt = $pdo->query("SELECT categoryID , categoryName FROM tbl_categories WHERE categoryActive = 1 ORDER BY categoryID "); $cat_options = []; /// store cat data in array foreach ($statement as $row) { $cat_options[$row['categoryID']] = $row['categoryName']; } // main loop here while ($row = $stmt->fetch()) { echo "<select name='categoryID' class='select200px' required> <option value=''>Select...</option>"; foreach ($cat_options as $id => $cat) { $sel = $row['categoryID'] == $id ? 'selected' : ''; echo "<option $sel value='$id'>$cat</option>"; } echo "</select>"; }

I don't know Postgresql. The problem you're going to have is that 1.10 is less than 1.9, In fact, it is equal to 1.1. If the Cast-Substribg works (again, I don't know Postgres), you should do it twice to split the version number. And order by the two values. Something like this CAST ( SUBSTRING ( movies.title FROM '#(\d+)\.\d+' ) AS INT ) AS major, CAST ( SUBSTRING ( movies.title FROM '#\d+\.(\d+)' ) AS INT ) AS minor ... ORDER BY major, minor You can use Integer now, instead of Decimal.

Sure. First, as mentioned before this is not SMTP, so all the SMTP_* constants you are using are either the wrong values or incorrectly named. Either make new IMAP settings to use or rename your constants. Second, this is based on some code I have that checks an email account for a one-time-password code so I can login and download data from a site. <?php //Example parameters. $host = '{imap.example.com:993/ssl/readonly}'; $mailbox = 'otp@example.com'; $password = ''; function getSecurityCode(string $host, string $mailbox, string $password) : ?string{ $authCode = null; $startTime = time(); do { sleep(5); $handle = imap_open($host, $mailbox, $password, OP_READONLY, 5); if (!$handle){ throw new RuntimeException('Unable to open mailbox'); } $messageList = imap_sort($handle, SORTDATE, 1); foreach ($messageList as $messageNumber){ $messageInfo = imap_fetch_overview($handle, $messageNumber)[0]; if (isOTPEmail($messageInfo) && isReceivedInLast5Minutes($messageInfo)){ $authCode = extractAuthCode(imap_body($handle, $messageNumber)); break; } } imap_close($handle); } while (!$authCode && time() - $startTime < 300); return $authCode; } function isOTPEmail(stdClass $messageInfo) : bool{ if (!isset($messageInfo->subject)){ return false; } return stripos($messageInfo->from, 'donotreply@example.com') !== false && stripos($messageInfo->subject, 'One-Time Passcode') !== false; } function isReceivedInLast5Minutes(stdClass $messageInfo) : bool{ if (!isset($messageInfo->date)){ return false; } $date = DateTime::createFromFormat(DateTimeInterface::RFC2822, $messageInfo->date); if ($date === false){ $date = DateTime::createFromFormat(DateTimeInterface::RFC2822 . ' (\G\M\T)', $messageInfo->date); } if ($date === false){ return false; } $now = new DateTime('', $date->getTimezone()); $now->sub(new DateInterval('PT5M')); return $date > $now; }

if you were doing this for real, where the price can change over time, the pricing would be stored in a related table, associated back to the token rows through the token's id, with a token_id, price, and effective start and effective end datetime columns. the point of the id column in this table is to assign a token id (auto-increment integer primary index), that would be stored in any related data table. this is the value that the form would submit for the selected token and would be stored in the usertoken table, not the token name. the balance is a derived value. you would not maintain the balance as a single value in a column, but would instead calculate it when needed. to do so, you need an account(ing) table, with a separate row inserted for each deposit/withdrawal that affects the account balance. also, the full name should be stored, using two columns, e.g. first_name, and last_name, so that you can uniquely distinguish between and search for people by name, e.g. is someone Ross Martian or Martian Ross? the account(ing) and usertoken table would use the id value from the users table, to related any stored data back to the correct user. this table should contain all the who, what, when, where, and why information about the purchase. the who would be the user_id of the buyer. the what would be the token_id, quantity, and purchase price (if you have a separate table for the pricing, you don't need this value). the when would be the datetime of the purchase. the where would only apply if there's a location associated with the purchase. the why would be a status/type value or memo field describing the reason for the purchase. this table doesn't need the account number, as that is defined in the users table and is known based on the user id. also, the totalbuy is a derived value that isn't stored. it is calculated when needed using the quantity and the purchase price (or the separately stored price at the datetime of the purchase.) the discount amount should be calculated and inserted as a separate row, in a related discount/interest accounting table, related back to the usertoken through the id in the usertoken table. you must do this as a single 'atomic' operation, in one query. the way to do this is use the query technique shown in this thread - https://forums.phpfreaks.com/topic/315532-avoid-appointment-conflict where you have an INSERT ... SELECT query that will only insert a new row in the usertoken table if the where clause calculates if the user's current balance - by summing the user's accounting rows, discount/interest rows, minus the user's existing token purchase amounts, is greater then or equal to the total amount of the submitted purchase. and just to clarify, the only two values submitted from the form should be the selected token id and the quantity. everything else should use values that only exist on the server.

Brilliant, Sherlock! If you had taken the trouble to read the (old and already fixed) post you would have seen that it already uses the modulo operator.