Если поле имеет тип данных TIMESTAMP, то абсолютно бессмысленно даже пытаться сунуть туда более точное значение, ибо оно будет округлено.
Определите тип поля как TIMESTAMP(6). И, поскольку автоматически присваиваемое значение уже определено, не упоминайте вообще это поле в запросе на вставку в списке полей, и, соответственно, не добавляйте для него значения в списке значений.
Евгений Лернер, Вы пробовали ответить, но попытка откровенно провальная. Попробую помочь.
Вариант 1. При отключении сервера данные пусть пропадают. После запуска накопление начнется заново, с нуля.
Вариант 2. Данные не должны пропасть. Следует обеспечить их сохранение и загрузку при следующем запуске.
Выберите один из двух вариантов.
Вы вообще знаете как работает inmemory db?
Вот не поверите - знаю.
Но InMemory DB и MySQL не соотносятся никак. Вообще никак.
PS. Да, эмуляция возможна. Но производительность будет скорее всего ещё хуже.
В контексте вопроса с учётом показанного кода это неверное утверждение.
В MySQL есть SELECT INTO OUTFILE/DUMPFILE, и не так уж и сложно построить запрос, который сформирует требуемое представление данных для выгрузки.
Вы обязаны начать с выкладывания результата выполнения SHOW CREATE TABLE Products;
Сейчас в принципе непонятно, есть ли у ODKU вообще материал для работы...
Если СУБД - а самом деле MySQL, то в незнании его синтаксиса. UPDATE не допускает никакого FROM.
Ну а если СУБД другая - то в неумении присвоить вопросу правильный тег.
А какие соображения заставили не использовать очевидный вариант хранения этих данных в одной таблице и раскидать данные по двум отдельным таблицам? Такая схема, с какой стороны не зайди, и неудобна, и просто нелогична, так что основания должны быть весьма вескими. И для имеющих смысл предложений нам бы было неплохо их узнать.
Можно попробовать поступить вообще наоборот - держать таблицу рабочих дней - нумерованно/сортированную. Тогда "крайний" срок просто считается плюсованием длительности периода допустимой просрочки к дате планового завершения. А для связной цепочки - просто суммировать эти допустимые просрочки отдельных этапов. Правда, и тут будет проблема - в момент начала выполнения задачи придётся всё пересчитывать, если задача начата не в плановый день.
Кстати, таблица пронумерованных рабочих дней поможет и в случае, если поступать экстенсивно - просто считать в глубину дерево работ.
И да - в обоих случаях сроки начала и окончания хоть и вводятся как характеристики, но далее будут чисто справочными, а расчёты должны оперировать посчитанной на их основе длительностью в рабочих днях.
Потому что phpMyAdmin авторизует тем пользователем, который указан в его конфиге, вероятно... или это в настройках PHP, поверх которого он работает.
PS. Убедись, что для этого твоего юзера testDB есть дефолтная БД.
А зачем тебе это o.created? какой в нём великий смысл? ну есть у юзера три разных значения, вывести можно лишь одно - ну и какое? кстати, сортировать по нему тоже бессмысленно, и по той же причине.
Если, скажем, нужно последнее - так выводи MAX(o.created). Если любое, лишь бы было в таблице - ANY_VALUE(o.created).
А лучше вообще не выводи.