Barand

Normalize your data and store it correctly... +-------------+ +-------------+ | subject | | class | +-------------+ +-------------+ +---------------+ +----| id | | id |---+ | class_subject | | | subj_name | | class_name | | +---------------+ | +-------------+ +-------------+ | | id | | +---<| class_id | | | subject_id |>--+ +---------------+ so that each class_id/subject_id pair is in it's own row... class_id subject_id | 58100 | 1 | 47270 | 1 | 95437 | 1 | 58100 | 2 | 47270 | 2 | 47270 | 3 | 95437 | 3

You should throw $e; not echo $e;

Catch the error. If it's a dupe key error (1062) then continue, otherwise throw the error try { insert a new row } catch (error) { if error number != 1062 { // if it's not a dupe error throw error // report it. } }

You won't if trying to enter a duplicate is throwing an error. Why is "path" the primary key? Do you ... want to prevent duplicate entries (which it is doing now)? or do you want to allow them and stop it reporting them? or do you want to prevent them but not report them if they are attempted?

One way is not to turn off the error reporting...

I know it's your database table. But you have designed it like a spreadsheet, which is completely the wrong approach. Data stored in a database needs to be correctly normalized (There's a link in my sig to a tutorial). For example, Dealername should be stored once in a dealer table with its id, not repeated in every row in this table. Only ids should be stored in multiple tables. Repeating columns likeyour months should be in separate rows. If, as I am guessing, a model belongs to particular category, the that category's id should be stored in the model table. It looks like there is also a dependency between dealer and category, but only you know that. If there is, then dealer id should be in the category table. I have no idea to which entity (dealer, category, model, year) the status belongs. Derived values, such as quarter and annual totals) should not be stored. Get those when needed with a query. Your tablename suggests you have a table for the current year although the data show two years (confusing, isn't it?). If you split your data by years it make historical reports a problem. I don't know the relationships between entities (you need to verify for youself), but the database should look something like this below, and not all stored in a single table. example data TABLE: target +-----+--------+------------+--------+--------+ | id | model | month | amount | status | +-----+--------+------------+--------+--------+ | 1 | GR170 | 2023-01-00 | 1 | 1 | | 2 | GR170 | 2023-02-00 | 2 | 1 | | 3 | GR170 | 2023-03-00 | 2 | 1 | | 4 | GR170 | 2023-04-00 | 1 | 1 | | 5 | GR170 | 2023-05-00 | 2 | 1 | +-----+--------+------------+--------+--------+

(Illustrating what mac_gyver has just told you.) What you have shown us is a spreadsheet table. Relational database tables are not spreadsheets - each row should contain a single value plus identifying attributes. Your spreadsheet contains several rows for each category/year. Why? What is distinctive about each row? Whatever it is, I have named the column "rowid?" +----------+--------+--------+--------+ | category | rowid? | date | amount | +----------+--------+--------+--------+ | user1 | 1 | 202301 | 1 | | user1 | 1 | 202302 | 2 | | user1 | 1 | 202303 | 2 | | user1 | 1 | 202304 | 1 | | user1 | 1 | 202305 | 2 | +----------+--------+--------+--------+ Then your query becomes SELECT category , sum(amount) as total FROM currentyeardata WHERE date BETWEEN '2023-01' AND '20203-05' GROUP BY category

If you store the dates the price was valid in the price table and match the sale date against them.

I regularly do the same thing with prices that change over time (date_from -date_until) so that historical reports use the price that applied at the time of sale.

Something like this... +---------------+ | invoice_item | +---------------+ | id | | prod_id |------+ | quantity | | +----------+ |---------------+ | | price | | +----------+ +-----<| prod_id | | minqty | | maxqty | | usd | | cad | | eur | +----------+ SELECT i.prod_id , p.product_name , pr.usd , pr.cadd , pr.eur FROM invoice_item i JOIN product p ON i.prod_id = p.id JOIN price pr ON i.prod_id = pr.prod_id AND i.quantity BETWEEN pr.minqty AND pr.maxqty

You could put them all in a single ini file EG contacts.ini ;; ;; constants definitions ;; [contactstate] 0 = Unactioned 1 = Actioned [contacttype] 1 = Query 2 = Suggestion 3 = Compliment code $constants = parse_ini_file('constants.ini', 1); echo $constants['contactstate'][1]; // Actioned echo $constants['contacttype'][3]; // Compliment You can use that ini file to create dropdown menu options too. Something that is a PITA with enum values/meanings. If you are using a database, put each of those ini sections in separate tables instead of the ini file method.

Don't worry about my suggestion not working - you shouldn't ever have a table designed like that. It should look like this, one value per row... userid | feed_id | attr_id | attr_value What does the CSV data look like?

Check your server's date/time settings. Looks like your default timezone is "Europe/Paris" or somewhere along that longitude. If you don't have control over the server settings then check your cPanel options for timezone settings. Failing that, set a default in your db connection procedure.

Your insert query needs to look like this INSERT INTO stock (userid, feed_id, c0, c1, c2, c3, c4, c5, c6, c7, c8, c9, c10) VALUES (?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?, ?) Your values to be inserted would be NULL (if not required) or the desired csv value. Also, do not prepare and bind i every iteration of the loop. Do those before the loop. Inside the loop you should just update the variables and execute.

What does this query give? SELECT @@session.time_zone as tzone, TIMEDIFF(NOW(), UTC_TIMESTAMP) as tdiff; As a fellow Brit I would expect to see ... +--------+----------+ | tzone | tdiff | +--------+----------+ | SYSTEM | 01:00:00 | +--------+----------+ ... meaning it is using your servers system time settings and currently British Summer Time

Your Norwegian characters worked for me... CREATE TABLE `user` ( `id` int(11) NOT NULL AUTO_INCREMENT, `firstname` varchar(20) DEFAULT NULL, `lastname` varchar(20) DEFAULT NULL, `user_name` varchar(30) DEFAULT NULL, `password` varchar(150) DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8; $pwd = 'Ææ, Øø, Åå'; // HASH AND STORE THE PASSWORD $stmt = $pdo->prepare("update user set password = ? where id = 2"); $stmt->execute([ password_hash($pwd, PASSWORD_DEFAULT) ]); // NOW CHECK THE PASSWORD STORED OK $res = $pdo->query("select password from user where id = 2"); $hash = $res->fetchColumn(); echo password_verify($pwd, $hash) ? 'VALID' : 'Oops!'; //==> VALID

Do your database , table and db connection all share the same utf8 encoding?

Why? Any keyboard characters, be they alphanumeric or spaces or punctuation, should be permitted (and encouraged) in passwords.

When you send an ajax request to a page, all output then goes into the response that is returned. (ie what you would see if you called that page in your browser is the reponse (which you can use to your advantage to test ajax responders). Remove the location header from the responder code and do the redirect in the calling page when you receive a succesful response.

Suggestions: 1. function timeDifference($datetime) { $periods = ['yrs', 'mths', 'days', 'hrs', 'mins', 'secs']; $dt1 = new DateTime($datetime); $dt2 = new DateTime(); $d = $dt1->diff($dt2); $diffs = array_filter(array_combine($periods, [ $d->y, $d->m, $d->d, $d->h, $d->i, $d->s ] )); $res = $d->invert ? '-' : ''; foreach ($diffs as $k => $v) { $res .= "$v $k "; } return $res; } echo "Now: " . date('Y-m-d H:i:s') . '<br>'; // Now: 2023-09-04 18:54:22 echo timeDifference('2023-09-04 19:00:00.000000'); // -5 mins 37 secs 2. You can also utilise SQL functions SELECT now() as Now , timestampdiff(SECOND, now(), '2023-09-04 19:00:00.000000') as Diff; +---------------------+------+ | Now | Diff | +---------------------+------+ | 2023-09-04 19:03:34 | -214 | +---------------------+------+ SELECT now() as Now , timediff('2023-09-04 19:00:00.000000', now()) as diff; +---------------------+------------------+ | Now | diff | +---------------------+------------------+ | 2023-09-04 19:08:39 | -00:08:39.000000 | +---------------------+------------------+

password_hash() and password_verify()

example... $client = 15; $res = $pdo->prepare("SELECT q.id , q.version FROM quote q JOIN ( SELECT client_id , max(version) as version FROM quote WHERE client_id = ? ) latest USING (client_id, version) "); $res->execute([ $client ]); list($quote, $version) = $res->fetch(PDO::FETCH_NUM); if ($quote) { try { $pdo->beginTransaction(); $stmt = $pdo->prepare("INSERT INTO quote (client_id, total_value, job_id, version, name, currency, kit_delivery, kit_return, quote_status_id) SELECT client_id, total_value, job_id, ?, name, currency, kit_delivery, kit_return, quote_status_id FROM quote WHERE id = ? "); $stmt->execute([ ++$version, $quote ]); $newquote = $pdo->lastInsertId(); $stmt = $pdo->exec("INSERT INTO quote_items (quote_id, item_id, quantity, start_date, end_date, notes, amount_charged_each, original_price_each, chargable_units) SELECT $newquote, item_id, quantity, start_date, end_date, notes, amount_charged_each, original_price_each, chargable_units FROM quote_items WHERE quote_id = $quote "); $pdo->commit(); } catch (PDOException $e) { $pdo->rollBack(); throw $e; } } else { echo "Client quotes not found"; }

Check your SQL reference manual for correct syntax (I'm used to mysql - I haven't used MSSQL since 2010) although I wouldn't be surprised if MSSQL's pathetic function library doesn't contain it. It's fairly simple to do it in PHP though. Create an array of names for each number the join() them. PS Looks like the mssql equivalent is STRING_AGG()

Then your data is not the same as mine. The data you posted had a "Month" key.

Use GROUP_CONCAT(M.Name SEPARATOR ', ') as name and GROUP BY P.Number