Столбец DateTime не работает в таблицах MS Access, связанных с серверной частью MySQL

У меня есть база данных MySQL с интерфейсом Microsoft Access (2016). У меня есть несколько связанных таблиц в базе данных Access, которые содержат столбцы DateTime.

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

WHERE [Date]=#01/01/2017# 

ничего не возвращается. Если я перепишу это на

WHERE CDate([Date])=#01/01/2017# 

он возвращает правильные записи (кстати, я выбрал эту дату, чтобы продемонстрировать, что это не проблема формата даты в Великобритании/США).

Столбец правильно отображается как столбец DateTime в связанной таблице во внешнем интерфейсе, и если я пишу запрос для отображения значений года, месяца и дня указанного столбца, он возвращает правильные значения.

Я использую Windows 10 Home, полностью обновленную, с Access 2016 MSO 16.0.7571.7063 и MySQL Connector/ODBC 5.3.6 на обеих машинах. Я не могу найти никаких других настроек в Access, которые различаются между двумя машинами, и, насколько я могу судить, мои региональные и языковые настройки также кажутся одинаковыми на обоих.

Я попытался преобразовать столбец MySQL в Date вместо DateTime, но это не имело никакого значения. Я также обновил, затем удалил и пересвязал таблицы версии на новом ноутбуке, и даже восстановил установку Office, но все равно без радости.

Кстати, если я скопирую связанную таблицу в локальную таблицу, она будет работать нормально.

Я понятия не имею, что может быть причиной этого. Поскольку все остальное кажется одинаковым, возможно ли, что какой-то параметр реестра на моем новом ноутбуке отличается от других моих компьютеров?

РЕДАКТИРОВАТЬ: я только что попробовал следующее предложение на ноутбуке

WHERE [Date]>=#01/01/2017# And [Date]<=#31/12/2016#

и он возвращает все записи!

ДОПОЛНИТЕЛЬНОЕ РЕДАКТИРОВАНИЕ: я также попытался выполнить следующий запрос

Select count([date]) from daysworked where [date]>=#dd/mm/yyyy#

в некоторых VBA для диапазона дат. Всякий раз, когда dd находится между 1 и 20 (включительно), он возвращает 1753 (все строки). Всякий раз, когда дд равно 21 или больше, он возвращает ноль независимо от значений мм и гггг. Мне кажется, что это может интерпретировать dd как значение века. Поскольку даты MySQL представлены в формате гггг-мм-дд, я полагаю, что это может иметь какой-то смысл, но я ожидаю, что коннектор ODBC будет иметь дело с преобразованием из формата Access в формат MySQL. И это явно работает на всех других машинах, на которых я это запускал.


person Lee Hill    schedule 03.01.2017    source источник
comment
Кстати, я использую 32-битную Unicode-версию драйвера MySQL ODBC.   -  person Lee Hill    schedule 04.01.2017
comment
У меня похожая проблема, но фильтрация дат дает сбой только при запуске файла accdb в терминальных службах Windows Server 2016. Если я запускаю тот же файл локально, он работает. В обоих случаях используется один и тот же драйвер ODBC, но нам пришлось возиться с ODBC версии 5.3 на сервере. Распространяемый компонент Visual C++ должен был быть установлен на сервере, чтобы установка ODBC работала. Я добавил CDate() вокруг ссылок на поле даты, и это исправило ситуацию. Приложение работает медленнее на терминальном сервере, поэтому драйвер ODBC может просто не устраиваться на этой версии ОС.   -  person Matthew MacFarland    schedule 04.10.2017


Ответы (3)


У вас есть временная часть? Что это вернет:

WHERE [Date] Between #01/01/2017# And #01/02/2017# 

Или попробуйте отобразить числовое значение на обеих машинах и сравните:

NumDate: CDbl([Date])

Или у вас действительно есть текст:

WHERE [Date] = '01/01/2017' 
person Gustav    schedule 04.01.2017
comment
Я подумал, что это может быть как-то связано со временем, поэтому я попытался изменить дату и время MySQL на обычную дату. Но предложенный вами вариант «Между» также ничего не возвращает. Как ни странно, если я попытаюсь ›=#01/01/2017#, я получу все записи. Они восходят к 28.07.2017 (британский формат). CDbl([Date]) правильно возвращает 42736 на 01.01.2017 на моем ноутбуке (я не смогу попробовать это на настольном ПК до сегодняшнего вечера). И нет, это не текст. Если я попытаюсь поместить дату в кавычки, я получу несоответствие типа данных. - person Lee Hill; 04.01.2017
comment
Извините, я имел в виду, что они возвращаются к 28.07.2008. - person Lee Hill; 04.01.2017
comment
То есть ›=#01/01/2017# возвращает не более поздние, а более ранние даты? Это действительно странно, на самом деле это невозможно, поэтому должно происходить что-то еще. Какой диапазон, скажем, вернет ›=#01/01/2010#? - person Gustav; 04.01.2017
comment
›=#01/01/2010# возвращает тот же диапазон, что и ›=#01/01/2017#. Я добавил пару правок к исходному вопросу, которые дают более «интересную» информацию. - person Lee Hill; 04.01.2017

Я создал новую БД на ноутбуке и добавил туда связанную таблицу, используя тот же ODBC DSN, и все работает нормально. Так что это должно быть как-то связано с конкретным файлом accdb, который я использую. Я не могу найти какие-либо настройки БД, которые бы это сделали, поэтому я начинаю подозревать коррупцию.

По крайней мере, это дает мне исправление, хотя и болезненное, для создания новой базы данных Access и перемещения в нее всех моих объектов. Но я хотел бы знать, почему это происходит только на моем ноутбуке, а не на любом другом ПК, на котором работает тот же файл accdb и тот же разъем ODBC.

person Lee Hill    schedule 04.01.2017
comment
Это может объяснить некоторые вещи. Из новой базы данных вы можете за один раз импортировать все объекты из старой. Но оставьте связанные таблицы и воссоздайте эти связи в новой базе данных. - person Gustav; 04.01.2017

Теперь я создал новую БД со всеми внутренними таблицами, добавленными как новые связанные таблицы, и это решило проблему.

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

person Lee Hill    schedule 04.01.2017