убиться... переменная показывает DMY, поиск по виду через DMY снова рулит... пипец, а говорят волшебства в ИТ не бывает!
-
Познакомьтесь с пентестом веб-приложений на практике в нашем новом бесплатном курсе
Формула поиска Notesdocument.search
- Автор темы dimat
- Дата начала
Вот, теперь дискуссия кажется входит в конструктивное русло. Давайте сравнивать.
Напомню, что речь шла о допустимости применения LocalTime в выражении типа Set dc=db.Search({@Created<[} + st.LocalTime + {]},Nothing,0).
Данное выражение вычислялось на локальном компьютере пользователя и применялось для поиска по БД, расположенной на удалённом сервере.
Я проверял следующим образом. Сделал агент
Код:
Sub Initialize
Dim ns As New NotesSession
Dim db As NotesDatabase
Dim st As NotesDateTime
Dim dc As NotesDocumentCollection
On Error Resume Next
Set db=ns.CurrentDatabase
Set st= New NotesDateTime(Cstr(Now))
Print st.LocalTime
Set dc=db.Search({@Created<[} + st.LocalTime + {]},Nothing,0)
If Err Then Print "[1] " & Error$ : Err = 0
Set dc=db.Search({@Created<[06/29/2010]},Nothing,0)
If Err Then Print "[2] " & Error$ : Err = 0
Set dc=db.Search({@Created<[29.06.2010]},Nothing,0)
If Err Then Print "[3] " & Error$ : Err = 0
End SubПолучили
[2] Notes error: Formula Error (@Created<[06/29/2010])
т.е. [1] и [3] отработали без ошибки
Потом в региональных настройках Windows менял настройки с русского на Engilish (US), при этом менялся и формат даты с ДД.ММ.ГГГГ на ММ/ДД/ГГГГ. Перезагузил Notes. Запустил агента.
Получили
[3] Notes error: Formula Error (@Created<[23.06.2010])
т.е. [1] и [2] отработали без ошибки.
Т.о. LocalTime сработала корректно под разными локалями в обоих экспериментах.
Серверная локаль в обоих экспериментах не менялась.
Первый Print печатал текущую дату в соответствии с текущей локалью, т.е. Notes использовал региональные настройки именно ОС.
ToxaRat
расскажите подробней, как Вы проверяли и какой эксперимент подтверждает ваше утверждение о недопустимости использования LocalTime в указанном контексте? Что означает термин "приходит сервер"?
TIA
Сечь как по мне работает следующим алгоритмом:
1) Клиент формирует строку и передаёт серверу
2) сервер отрабатывает команду сёчь со сторокй и возвращает клиенту коллекцию - сечь выполняется средствами сервера а не клиента
Если сервер не поймет строку это вызовет ошибку, простое изменение формата времени на сервере может вызвать ошибку на сечь и не важно какой формат времени у клиента, его локаль в данном случае для сервера это просто строка - набор символов, которые сервер попытается отработать правильно, но все варианты он не учтёт
вот она ваша ошибка, вы надеетесь и привязываетесь к серверной локали выражения типа 06/29/2010 сервер умеет правильно переводить в отличии от 06.29.2010
Сечь как по мне работает следующим алгоритмом:
1) Клиент формирует строку и передаёт серверу
2) сервер отрабатывает команду сёчь со сторокй и возвращает клиенту коллекцию - сечь выполняется средствами сервера а не клиента
Если сервер не поймет строку это вызовет ошибку, простое изменение формата времени на сервере может вызвать ошибку на сечь и не важно какой формат времени у клиента, его локаль в данном случае для сервера это просто строка - набор символов, которые сервер попытается отработать правильно, но все варианты он не учтёт
Доказать сможете?
На ваш аргумент я отвечу следующее.
Клиент тоже не выдаёт синтаксической ошибки на дате 01/02/2009, когда настройки ДД.ММ.ГГГГ, а вот на дате 16/11/2009 уже выдаёт ошибку. Т.е. он пытается распознать дату, но когда ему не удаётся - генерируется эксепшен.
Ещё в подтверждение своей гипотезы приведу кусок NRPC-лога. Кто не знает, NRPC - это Notes Remote Procedure Call - протокол общения Notes-клиента с сервером. Агента запускал того же под локалью с ДД.ММ.ГГГГ. Также я включил режим протоколирования вывода в статус бар.
[096C:0002-0F40] (123-299 [128]) READ_OBJECT(REPC325735C:003B7AB5-RRV0000073E,0x10 at 0x140): 0 ms. [26+36=62]
[096C:0002-0F40] (124-299 [129]) GET_NOTE_INFO_BY_UNID: 0 ms. [52+66=118]
[096C:0002-0F40] (125-299 [130]) OPEN_NOTE(REPC325735C:003B7AB5-NT000006A2,03400000): 0 ms. [48+5238=5286]
[096C:0002-0F40] 16.11.2009 15:31:52 Status Msg: 16.11.2009 15:31:52 ZE3
[096C:0002-0F40] (126-299 [131]) SEARCH: 157 ms. [94+706=800]
[096C:0002-0F40] 16.11.2009 15:31:52 Status Msg: [2] Notes error: Formula Error (@Created<[06/29/2010])
[096C:0002-0F40] (127-299 [132]) SEARCH: 188 ms. [94+706=800]
[096C:0002-0F40] (128-300 [133]) GET_OBJECT_SIZE: 0 ms. [28+24=52]
[096C:0002-0F40] (129-300 [134]) WRITE_OBJECT(REPC325735C:003B7AB5-RRV0000073E,0x30 at 0x0): 0 ms. [74+12=86]
NRPC-вызов [131] - это Search под номером 1 в агенте.
Далее, вместо Search под номером 2 вывелось сообщение об ошибке в статус бар.
И [132] NRPC-вызов это Search под номером 3.
Других SEARCH нет. Значит, никакого запроса на сервер по второму Search не передавалось. Значит серверу даже не дали шанса "перевести", как Вы выразились, эту дату.
товарисч, с такой терминологией!... хорошо я хоть до вечера понял, что это поиск! )))
ToxaRat
Я по прежнему утверждаю, что высказанное вами замечание по поводу допустимости применения LocalTime (причём в резкой и неуважительной форме) является чушью.
То, что я утверждаю было написано уже трижды с разной степенью детальности. Формат даты может влиять, а может и не влиять на корректное выполнение запроса. Корректность зависит от способа определения этого запроса, контекста вычисления скрипта, формирующего запрос и контектста выполнения запроса. Пример, когда способ задания даты в поисковом запросе влияет на выполнение запроса я тоже приводил.
Я по прежнему утверждаю, что высказанное вами замечание по поводу допустимости применения LocalTime (причём в резкой и неуважительной форме) является чушью.
То, что я утверждаю было написано уже трижды с разной степенью детальности. Формат даты может влиять, а может и не влиять на корректное выполнение запроса. Корректность зависит от способа определения этого запроса, контекста вычисления скрипта, формирующего запрос и контектста выполнения запроса. Пример, когда способ задания даты в поисковом запросе влияет на выполнение запроса я тоже приводил.
воще миня смущаеть одно:
Read-write. A string representing a date-time, in the local time zone.
т.е. прямо не касабельно формата представления
и берёть оно энту хрень с учётом локейшн, а сталобыть еще надо смореть и локейшен адвансед
И учит. - сразу ли оно педернецо попсля смены локали в ОС?
у мя подозрение - могет и не подхватить...
потому - для чистоты эксперимента https://codeby.net/threads/32749.html?vi...st&p=152429
надо логоф/логон делать
Read-write. A string representing a date-time, in the local time zone.
т.е. прямо не касабельно формата представления
и берёть оно энту хрень с учётом локейшн, а сталобыть еще надо смореть и локейшен адвансед
И учит. - сразу ли оно педернецо попсля смены локали в ОС?
у мя подозрение - могет и не подхватить...
потому - для чистоты эксперимента https://codeby.net/threads/32749.html?vi...st&p=152429
надо логоф/логон делать
Виндовый логоф или Нотусовый? Нотусовый я делал (перезагрузкой Нотес) и ещё печатал
Print st.LocalTime
Смена формата даты подхватывалась и печаталась в формате уже модифицированной локали. Т.о. все возможные настройки, которые могли повлиять на формат строки с датой контролировались путем проверки конечного результата.
Хорошо. Я ребутнул и винду. Результат абсолютно такой же. Хотя, мог бы и сам попробовать. Код агента даже уже есть.
могбы, при условии наличия тестовой среды (LDN) в винде (виртуальной - нативной не держу)
но раз уж сам взялся тестить...
вот она ваша ошибка. клиент не передает строку серверу. не стройте гипотез, а почитайте хелп:
Ссылка скрыта от гостей
это фантазии.
сервер не парсит условие поиска, переданное клиентом и не пытается учитывать никакие варианты.
оно( условие поиска ) передается в компилированном виде.
и ключевой момент - правильная компиляция формулы(NSFFormulaCompile) на клиенте. Если дата в формуле согласуется с локалью клиента - все отработает верно.
про внутренне представление даты можно покурить здесь:
Ссылка скрыта от гостей
З.Ы. Чтоб снять вопросы относительно того, что уходит на сервер, используем снифер:
Код:
Dim ns As New NotesSession
Dim db As NotesDatabase
Set db=ns.CurrentDatabase
Dim st As New NotesDateTime(Cstr(Now))
Dim dc As NotesDocumentCollection
Stop ' здесь включаем снифер, напр tcpdump.exe -X -s0 -i 2 dst port 1352
Call db.Search({@Created<[} + st.LocalTime + {]},Nothing,0)
Stop ' выключаем снифер( 17 nov 2009 ) - ( 10 dec 1996 ) = 4,725 дней + 2,450,428 = 0x257671
смотрим, что ушло на сервер и видим во втором пакете искомые цифры: 71 76 25.
Надеюсь, что окончательно развеял ваше заблуждение.
turumbay
а на мой вопрос ответишь?
https://codeby.net/threads/29430.html
можешь объяснить причину? и ее самостоятельное исчезновение?
а на мой вопрос ответишь?
https://codeby.net/threads/29430.html
можешь объяснить причину? и ее самостоятельное исчезновение?
turumbay
я теперь еще и к вот этому придерусь
К сниферу претензий нету, но думаю ситуацию мы тут не всю прозрачно видим.
Мучительно вспоминая по сечу и почему я столь категоричен к нему, вспоминаю вот такую ситуацию:
У пользователя установлен в ОС формат даты "dd-mm-yy" - у него там досовские програмки, которые только такой формат ели и отчеты так выводили
Поставили ему лотус, может формат ОС, расходился с форматок даты в клиенте но .Search у него всё время вылитал на ошибку
Как это доказать не наю, да и не особо горю, всё равно каждый бужет писать так как ему удобнее, но факт есть факт.
Я вас предостерёг, хотите слушайте - хотите нет.
я теперь еще и к вот этому придерусь
так писать нельзя, только "" с командой .SetNow
К сниферу претензий нету, но думаю ситуацию мы тут не всю прозрачно видим.
Мучительно вспоминая по сечу и почему я столь категоричен к нему, вспоминаю вот такую ситуацию:
У пользователя установлен в ОС формат даты "dd-mm-yy" - у него там досовские програмки, которые только такой формат ели и отчеты так выводили
Поставили ему лотус, может формат ОС, расходился с форматок даты в клиенте но .Search у него всё время вылитал на ошибку
Как это доказать не наю, да и не особо горю, всё равно каждый бужет писать так как ему удобнее, но факт есть факт.
Я вас предостерёг, хотите слушайте - хотите нет.
И снова безосновательно.turumbay
я теперь еще и к вот этому придерусь
так писать нельзя, только "" с командой .SetNow
это лирика
Неправильно это - рубить человеку голову за конструкцию только потому, что вы не понимаете как она работает.
Резюмируя топик - использование в db.search NotesDateTime.LocalTime безопасно и обосновано.
db.ftsearch - выполняется в контексте хозяина индекса. строка запроса идет на сервер некомпилированная, парсинг происходит на сервере.а на мой вопрос ответишь?
https://codeby.net/threads/29430.html
можешь объяснить причину? и ее самостоятельное исчезновение?
это все хорошо, но почему-то поведение сервера не отвечает логике наших мыслей и догадок
Обучение наступательной кибербезопасности в игровой форме. Начать игру!