Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Microsoft Access Новый топик    Ответить
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
 Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Исходные данные: руссифицированные MS Access 2003, Windows 7(у меня) и 10(у клиента).
Никак не могу понять что происходит. В запросе есть условие вида:

e.[Дата] BETWEEN Forms![WorkReport].DateFrom And Forms![WorkReport].DateTo

где DateFrom и DateTo объявлены как свойства типа Date, поле e.[Дата], разумеется, тоже дата, в смысле, native-datetime. Запрос является базовым для отчёта, который показывает записи за указанный период. У меня на компьютере всё прекрасно работает абсолютно независимо от региональных установок и способов, на компьютере же клиента, для которого по просьбе и правится старая уже программа, не работает ни один из многочисленных перепробованных мною вариантов. Никакие преобразования не срабатывают.
Например:

BETWEEN CDate(Forms![WorkReport].DateFrom) And CDate(Forms![WorkReport].DateTo)

и вовсе выдаёт известную ошибку о слишком сложном выражении. Формально, я знаю, что в Access SQL по сути единственным гарантированным выражением для даты является американский(#m.d.yyyy#), в который обычно легко преобразуется локальный при подстановке параметров запроса, например. Вроде как должна работать подстановка функций, возвращающих дату, как пример:

BETWEEN FuncDateFrom() And FuncDateTo()

Так вот на моём компьютере работает абсолютно все перечисленные варианты, у клиента-же, как заговорённый, никаких вариантов, кроме прописывание дат как литералов в американском стиле. Я безусловно могу везде, где это надо, жестко прописывать дату в этом стиле, но очень хотелось бы, чтобы всё-таки у клиента работало также, как на моём компьютере. Собственно, в этом и вопрос: может кто-то разбирался плотно, что на так может влиять на поведение в восприятии дат в Access SQL ? Версия Access у клиента и меня совпадают, правда у меня SP3, у него пока не узнавал, возможно это влияет. Просто не хочется мусорить литералами и постоянными преобразованиями в американский формат, очень некрасиво.
25 май 21, 22:57    [22327142]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Upd. У клиента тоже SP3 и как выяснилось, формат воспринимается только #YYYY-MM-DD# и #YYYY/MM/DD#. Остальные, кажется, даже американский, нет. Просто феерия какая-то :(
25 май 21, 23:10    [22327147]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
sdku
Member

Откуда: Краснодар
Сообщений: 7350
ChA
... Просто не хочется мусорить литералами и постоянными преобразованиями в американский формат, очень некрасиво.
Десяток лишних нажатий клавиш при использовании FORMAT - все проблемы/непонятки исчезнут. А чтоб разобраться почему так происходит Вы убъёте намного больше времени
Ваше стремление к "красоте",по-моему,уж очень избыточно.Ну где тут не красиво?(Тем более что это может быть пользовательская функция преобразующая дату к американскому стандарту)
Me.дата>=#" & FORMAT(Forms![WorkReport].DateFrom,"mm\/dd\/yy") & "# and me.дата =<#" & FORMAT(Forms![WorkReport].DateTo,"mm\/dd\/yy") & "#"
И посмотрите региональные настройки

Сообщение было отредактировано: 25 май 21, 23:35
25 май 21, 23:43    [22327162]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
vmag
Member

Откуда: MP
Сообщений: 4029
ChA,
У клиента скорее всего не так как на картинке
И если это изменить нельзя - я писал функцию, которая точно возвращала нормальную дату

К сообщению приложен файл. Размер - 119Kb
25 май 21, 23:58    [22327166]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
vmag
Member

Откуда: MP
Сообщений: 4029
ChA,

И да, как уже выше намекнули, BETWEEN более капризен чем >= And <= (в акцессе) как мне показалось....

Сообщение было отредактировано: 25 май 21, 23:55
26 май 21, 00:03    [22327167]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
vmag
У клиента скорее всего не так как на картинке
И если это изменить нельзя - я писал функцию, которая точно возвращала нормальную дату
Самое забавное, что у клиента как раз такое и стояло, это у меня уже старая привычка определять формат как YYYY-MM-DD, но игрища с изменениями формата не сыграли ни малейшей роли, у меня по-прежнему работали все варианты, у клиента нет, даже если он ставил краткий формат даты как у меня. Собственно, формат и не должен играть ни малейшей роли, если я однозначно определяю, что-то как дату. И свойства, которые я делал, по сути те же самые функции с указанным явно типом даты, там точно так же делается присвоение, как если бы я написал функцию. И у меня на компьютере это работает, а у него нет, вот в чём проблема. Я слишком давно активно работал с Access, уже лет 20 прошло и уже подзабыл про его закидоны, а вот теперь опять пришлось вспомнить
Это явно какая-то фигня, но всё что я просмотрел заново на эту тему, сводится либо к DateSerial, либо к литералам в американском стиле, хотя повторюсь, у меня на компьютере всё прекрасно работает без каких-либо литералов. Понадеялся, что может кто-то разобрался досконально с этим вопросом, но по ходу, увы, всё те же, всё так же.
26 май 21, 00:21    [22327170]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
alecko
Member

Откуда: Башкирия
Сообщений: 797
ChA, может отстать от запроса и формировать фильтр в команде открытия? есть и более сложный способ (и универсальный) фильтрации(или формирования) данных через openArgs
26 май 21, 09:15    [22327232]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
alecko
формировать фильтр в команде открытия? есть и более сложный способ (и универсальный) фильтрации(или формирования) данных через openArgs
Я не спрашивал о том, как сделать по-другому, я прекрасно знаю все эти убогие способы передачи параметров в формы/отчёты через текстовую строку. Меня интересовало другое, вдруг кто-нибудь разобрался досконально и знает почему на одних компьютерах прекрасно работают все варианты работы с датой, включая функции, а на других - только через "правильный" формат.
26 май 21, 12:26    [22327367]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
sdku
Member

Откуда: Краснодар
Сообщений: 7350
ChA,
Смотрю на Ваше первое сообщение и возникает тривиальнейший вопрос: а в реале дата обрамлена решетками?
26 май 21, 12:27    [22327369]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
sdku
Смотрю на Ваше первое сообщение и возникает тривиальнейший вопрос: а в реале дата обрамлена решетками?
Не понял вопроса. Дата должна обрамляться, если она литерал, а их я как раз и не хочу использовать, ибо это неправильно. Тем более что речь об именованном сохранённом запросе, который используется в отчёте, а не как источник для рекордсета. У клиента изначально вообще абсолютно тупо менялся текст такого именованного запроса перед его вызовом как раз таким образом, с подобным форматированием конкретно заданными значениями даты. Теперь представьте такой вариант в многопользовательской среде, когда несколько человек пытаются одновременно использовать такой запрос в форме и каждый со своими значениями даты. Думаю не надо пояснять, насколько это неправильно, начиная с того, что пользователь не должен иметь возможность модифицировать именованный запрос в принципе.Поэтому меня не интересуют способы передачи даты как строки с # или без них, это я уже от безнадёжности начал экспериментировать, чтобы понять, что там у клиента в принципе работает. В случае строки запроса для "свободного" рекордсета прекрасно работают PARAMETERS, что тоже исключает необходимость в #. Таким образом, я в принципе не хотел связываться с форматированием значений даты в строке. Передача дат ли, чисел ли конвертацией в текст, давайте уж начистоту, это убого. И на моём компьютере всё, что я хотел, работает прекрасно, а вот у клиента нет, это и было главным моим вопросом, а не то, какие специи надо добавить, чтобы кошка получилась вкусной.
26 май 21, 16:38    [22327557]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
sdku
Member

Откуда: Краснодар
Сообщений: 7350
гляньте это(в конструкторе запросов и VBA синтаксис разный):

К сообщению приложен файл (tmp1.rar - 16Kb) cкачать
26 май 21, 17:30    [22327591]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
Панург
Member

Откуда: настоящему индейцу завсегда везде ништяк
Сообщений: 5230
ChA, в другой (тестовой, созданной с нуля) такие же проблемы?
26 май 21, 19:07    [22327636]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
sdku
Member

Откуда: Краснодар
Сообщений: 7350
ChA
.... И на моём компьютере всё, что я хотел, работает прекрасно, а вот у клиента нет...
Ну и как Вы думаете, в чем проблема?
"Давайте уж начистоту"-не надо искать черную кошку в темной комнате ,когда её там нет

Сообщение было отредактировано: 26 май 21, 19:26
26 май 21, 19:32    [22327644]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
sdku
гляньте это(в конструкторе запросов и VBA синтаксис разный):
Прости, конечно, но я в курсе:) Еще раз, я вообще не хочу использовать литералы, если это в принципе возможно.

В модуль твоей формы я добавил
Public Property Get FromD() As Date
FromD = Me.Поле7
End Property

Public Property Get ToD() As Date
ToD = Me.Поле10
End Property

Скопировал твой запрос с другим именем и немного его поменял
SELECT Таблица1.дата, Таблица1.зн
FROM Таблица1
WHERE (((Таблица1.дата) Between Формы!Таблица1.FromD And Формы!Таблица1.ToD));
И запрос открывается и показывает ровно то, что должен, без литералов и #. Вот я и хочу, чтобы у клиента работало так же.
26 май 21, 19:33    [22327646]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Панург
ChA, в другой (тестовой, созданной с нуля) такие же проблемы?
Дело в том, что клиент удалённый, я не могу экспериментировать на его компьютере База разделена на данные и приложение, я ему пересылаю только исправляемое приложение, он проверяет, работает или нет. Я его и так уже загонял, но пока без толку. Кстати, вначале это было монолитное приложение два-в-одном, я программно разделил его на приложение и данные кодом, так что БД и так можно сказать с "нуля".
26 май 21, 19:41    [22327653]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
Панург
Member

Откуда: настоящему индейцу завсегда везде ништяк
Сообщений: 5230
ChA
Дело в том, что клиент удалённый, я не могу экспериментировать на его компьютере
но надо как-то решить проблему? Возможно файл фронтэнда испорчен, а возможно что-то с приложением... Клиенту это тоже нужно. Сейчас полно способов получить санкционированный дистанционный доступ к машине.
26 май 21, 20:14    [22327667]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
Кривцов Анатолий
Member

Откуда:
Сообщений: 620
ChA, у вас два свободных поля на форме, и в свойствах указан один из стандартных форматов даты. Я правильно понял? Это важно.
26 май 21, 20:15    [22327668]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Панург
но надо как-то решить проблему? Возможно файл фронтэнда испорчен, а возможно что-то с приложением... Клиенту это тоже нужно. Сейчас полно способов получить санкционированный дистанционный доступ к машине.
С файлом приложения всё нормально. Как я уже писал ранее, я пересылаю клиенту свою копию, которую он и запускает. А с доступом сложнее, эта программа стоит в государственной организации, где работают с закрытыми персональными данными, так что мне нельзя подключиться туда ни под каким соусом. Максимум, я могу попросить о каких-то технических деталях. Программа изначально написана как любительская, но не очень хорошо, поэтому решил помочь людям, которые делают важные дела. С моей стороны, это чисто благотворительный акт, простое желание помочь, никаких официальных отношений.
Кривцов Анатолий
ChA, у вас два свободных поля на форме, и в свойствах указан один из стандартных форматов даты. Я правильно понял? Это важно.
Не совсем, исходно, у меня не текстовые поля, а стандартный объект-календарь(MSCAL.Calendar.7), мог обращаться напрямую к нему, но решил всё-таки получать значения через RO-свойство формы типа Date, аналогично приведённому выше примеру. Один из последних проверяемых вариантов
Public Property Get DateFrom() As Date ' вернуть дату начала периода
DateFrom = DateSerial(Me!axDateFrom.Year, Me!axDateFrom.Month, Me!axDateFrom.Day)
End Property

У меня-то работают практически любые варианты, в том числе и без DateSerial, это уже просто от безнадёги, на авось, хотя выглядит глупо, так как всё равно возвращается тип Date. Если бы не смогло конвертироваться, то вылетала бы ошибка при запуске запроса, как у клиента :) Первоначальный вариант был проще
Public Property Get DateFrom() As Date ' вернуть дату начала периода
DateFrom = Me!axDateFrom
End Property
и у меня он тоже работал.
Я уже подумывал, что это связано с тем, что я всегда в ОС выставляю себе краткий формат даты, совпадающий с ISO - YYYY-MM-DD, но когда клиент попробовал поменять у себя на такой же, то ничего не изменилось, кроме отображения дат, а код как не работал, так и не работает.
26 май 21, 21:17    [22327684]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
Кривцов Анатолий
Member

Откуда:
Сообщений: 620
ChA, ссылки на элементы формы в запросах - инородное тело для SQL. А ActiveX элемент - инородное тело для Акса. Где-то здесь собака и порылась. Лучшее решение - заменить это хозяйство на два обычных поля и всплывающий календарик. В свежих версиях Акса он уже есть.
28 май 21, 16:23    [22328551]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Кривцов Анатолий
ссылки на элементы формы в запросах - инородное тело для SQL
Разумеется, выглядит на редкость уродливо, но других-то вменяемых вариантов всё равно нет. Попытка скрестить коня и лань, jet и vba, абсолютно провальна, учитывая несовпадение типов. Прежде всего, именно типа даты, что особенно умиляет, так как на практике он один из самых необходимых в БД. И самое удивительное, в самом Jet SQL нет никаких функций конвертации данных типа CAST/CONVERT, что решило бы большинство подобных проблем. Ведь даже параметры у запроса есть, но и тут недоработали, так как нет простого способа подставить их в запрос, который используется в качестве источника данных для формы/отчета. Причем неявная подстановка параметров в запрос, используемый в качестве источника данных для элементов управления в форме, вполне возможна, хотя и смахивает больше на чит, так как нигде явно не декларирован. Впрочем догадаться о нём несложно, так как ноги идут из тех же ссылок на форму. Зато Access анализирует тип bounded-поля, чтобы понять тип Value, это прямо facepalm какой-то. Даже интересно, кому в MS пришла такая оригинальная идея ?
Кривцов Анатолий
ActiveX элемент - инородное тело для Акса.
Тут я не готов согласиться, очень даже удобная вещь для расширения функциональности.
Кривцов Анатолий
Где-то здесь собака и порылась.
Вот я и хотел понять, где именно, и почему на одном компьютере конвертация срабатывает вполне ожидаемо, а на других - никак.
Кривцов Анатолий
Лучшее решение - заменить это хозяйство на два обычных поля и всплывающий календарик. В свежих версиях Акса он уже есть.
Ну во-первых, это не решает мою задачу, а Jet SQL, внезапно, прекрасно "понимает" прямую ссылку на поле-календарь. И еще он, судя по всему, "понимает", если ему в условие в качестве даты подсунуть её же в целочисленном варианте, как бы неестественно это не смотрелось. Во-вторых, я не искал советов, как сделать по-другому, все предложенные тут способы знал ещё в 90х, так как довольно много писал на MS Access. Просто надеялся, что в 2003, с которым мне уже не пришлось поработать, предложили что-то более вменяемое, но увы, как выяснилось. Ну и в-третьих, исходные постановка подразумевает MSA2003. Лучшее решение, вообще реализовать требуемую функциональность на чём-то более вменяемом, но, увы, здесь тоже есть нюансы, руки связаны.

P.S. В принципе, тему для себя закрываю. Ничего нового, к сожалению, я не увидел
29 май 21, 01:00    [22328723]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
Прогер_самоучка
Member

Откуда:
Сообщений: 69023
ChA
Кривцов Анатолий
ActiveX элемент - инородное тело для Акса.
Тут я не готов согласиться, очень даже удобная вещь для расширения функциональности.
может и удобная.
Но Анатолий прав, активы - вне акса, их применение на свой страх и риск.
29 май 21, 11:54    [22328754]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Прогер_самоучка
ChA
удобная вещь для расширения функциональности.
их применение на свой страх и риск.
Любое использование компонентных технологий на свой страх и риск, но на то они и компонентные, чтобы не писать всё самому. ActiveX - обычный OLE-объект, который следует заданному протоколу обмена данных между приложениями и в среде Windows они сплошь и рядом. Впрочем, ваше право отказаться от их использования, а заодно и от чужих библиотек, и всего, что обнаружите в списке ссылок Access-проекта, а заодно и от самого Access. Всё сами, собственными руками, такая практика имеет место быть.

P.S. Вот обо всём мне рассказали, кроме того, что я действительно хотел узнать
29 май 21, 14:18    [22328782]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
court
Member

Откуда:
Сообщений: 2339
ChA
P.S. Вот обо всём мне рассказали, кроме того, что я действительно хотел узнать

дык, ты бы хоть сообщение ошибки привёл, чтоле ... а то "не работает" и понимай как знаешь
29 май 21, 14:21    [22328783]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
court
Member

Откуда:
Сообщений: 2339
ChA
ActiveX - обычный OLE-объект, который следует заданному протоколу обмена данных между приложениями и в среде Windows они сплошь и рядом.

они-то, "сплошь и рядом", только даже на одной версии ОС, запросто "оказуются" разных версий
А с учётом "дурацкой" черты Акцесса "залипать" на ту версию, на которой компилировался проект, - доставляют много дополнительных "радостей", типа компилирования на конкретной машине :)
29 май 21, 14:31    [22328785]     Ответить | Цитировать Сообщить модератору
 Re: Вопрос о сравнении дат  [new]
ChA
Member

Откуда: Москва
Сообщений: 11310
Решено. На всякий случай, опишу причину проблемы, описанной в стартовом топике, вдруг кто-то ещё окажется в подобной ситуации. У клиента стояла безопасность(Сервис/Макрос/Безопасность...) на среднем уровне. В результате, процедуры из объектов MS Access, в данном случае - форм, не запускались внутри Jet SQL.
1 июн 21, 18:36    [22330021]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: [1] 2   вперед  Ctrl      все
Все форумы / Microsoft Access Ответить