Насчет неявных полей - не проверял и не думаю, что дело в чем-то таком.
Есть два стулае таблицы. Структуры таблиц и типы полей идентичны таким же таблицам из Microsoft SQL Server. Тексты запросов не менял (за исключением ТОР(field)). В одну таблицу аксес нормально все записывает, а во вторую не может, выбрасывает исключение Несоответствие типов данных в выражении условия отбора. Уже думаю побуквенно всё сравнивать

В общем, проблема была в том, что драйвет JET не может нормально сконвертировать значение DateTime вида дд.ММ.гггг ччммсс и записать его в базу. Даже если поставить тип поля Текстовый, все равно какие-то проблемы с записью. При этом, если этот же самый запрос выполнить в редакторе и с такой же датой, то нормально пишется
Также пробовал привести дату и время к американскому формату, но ошибка осталась. На древних форумах нашел решение - предлагают сменить отображение даты в ПК на ММ/дд/гггг, тогда все должно заработать. Решение гениальное 👍
Но я не стал дальше проверять, убедил заказчика воткнуть localdb хотя бы, чтобы нормальный sql использовать

Витаминыч, яма, почему время не в мс хранится?

Витаминыч, а почему время не хранить в int?

Потому что время грузится из эксель файла

Витаминыч, а преобразовать в timestamp и хранить в int?
В php есть strtotime, я думаю, есть аналоги или возможность накатать такую функцию где угодно.

web_demon, а зачем? Дата считывается как есть (генерируется своеобразный отчет, этот отчет надо загнать в базу в неизменном виде, вполть до порядка столбцов), как есть пишется в БД и потом считывается в другом месте в неизменном виде. Проблема то не в том, как хранить, а какого черта в MS Access оно не хотелось записываться точно так же, как в MS SQL Server. Суть то в том, что в сервер нормально все пишется, без всяких конвертаций, потому что драйвер сам готовит данные (из string или object). Но стоило мне заменить SqlConnect на OleDbConnect, как что-то пошло не так, драйвер поломался. Это я не беру даже в расчет, что остаток от деления (% в сервере и mod в ацессе) и команда TOP пишутся по разному.

А так да, в C# есть вроде парсинг даты как число тиков, только про это редко вспоминаю, т.к. практически всегда работаю с датой как с датой. Тот же DatePicker (виджет календаря) возвращает дату/время как дд/ММ/гггг чч.мм.сс, отдельно писать метод для конвертации туда-сюда нет смысла. Вот если нужно будет API сделать, то тут я бы конечно в int перегнал бы. А там дальше как и чем хотят пусть обрабатывают. Как я понял, там кто-то где-то делфи до сих пор юзает и поэтому из-за этого много ограничений случается. Я такие страшные таблицы встречал, что руки потянулись хотя бы немного разгрузить, но меня отругали. Хотя это забавно: есть PK, но они ни с чем не связаны. Все места, где было бы логично настроить связи между таблицами, там вручную id забивают. Их проблемы в общем, я свои задания выполнил

Витаминыч, ну потому что это удобно. У тебя всегда один формат, который любой другой человек понимает как работает и он работает везде одинаково в любом языке. Плюс если тебе будет нужен будет поиск по времени, это легко будет сделать.
По мне лучше потратить время на конвертацию, и в 100% получить результат, чем потом разбираться в том как и какой драйвер багует при работе с датой.

web_demon, согласен, но конкретно в этом случае все упирается в эксель и в людей, кто с этим работает. В экселе то можно из коробки timestamp конвертировать через формулу (ячейка/86400)+DATE(1970,1,1), но, как я писал, файл генерируется по определенным правилам, и я это поменять не могу. Как я понял, время в привычном формате генерирует китайский контроллер, прошивки от которого нет и в его конфигураторе таких настроек тупо нет.

Я мог бы добавить пару методов по конвертации файлов в программку, но заказчику этого не нужно, в детали я не вдавался, почему потом у них могут быть сложности с обработкой данных. Думаю, обрабатывать их будут вовсе не программисты, если всё так сильно завязано на экселе. В общем, задача такова и больше некакова

web_demon, не, для веба оно мб и норм, использовать timestamp, но в mssql говно идея. Там есть нормальный тип DateTime, что в БД, что в C#. Всё само приводится к нужному виду. Если другой программист с# в программе использует стандартный тип и запросит из моей бд дату, ожидая получить дату, то получит исключение, потому что возвращается не то, что ожидается. Т.е., конвертер писать придется не только мне, но и прочим => пустая работа.