Форум » Clipper » ax_setServerAOF(cExpr): длина выражения cExpr чем-то ограничена ? » Ответить
ax_setServerAOF(cExpr): длина выражения cExpr чем-то ограничена ?
p519446: hi all subj. Мну почему-то показалось однажды, что после 250 будут траблы. Но то был АДС 6.11 Давно уже сижу на 7.0, проверил только что на выражении в 570 знаков - ax_EvalServerAOF() показывает результат >0, т.е. ошибки нету. Кто-нить исследовал эту тему ?
Ответов - 15
Dima: ага , ограничена. читай тут
p519446: --- quote --- Maximum traditional record filter expression text length 65,534 characters --- quote --- бгы... наглая бесстыдная ложь... на 570-символьном выражении (синтаксически корректном) установка "традиционного фильтра записей" выплёвывает "Operation too complex" :-) Фильтр имеет вид: !(CHR(255) $ NAME).AND.(NO="1234".OR.NO="2345".OR. <...> .OR.NO="9876")
Dima: p519446 пишет: бгы... наглая бесстыдная ложь... Ну может для Clipper эта цифирь и поменьше будет и глядеть надо другой тутор
p519446: клипперное ограничение меня мало интересует: почти все фильтры идут через АДС. К счастью, я нигде жестко не кодировал магическое число типа "250", везде указана константа компиляции. Надо будет поэкспериментировать и увеличить её.
Dima: Крутятские у тебя фильтра (в смысле длинные) Для чего нужны такие ? Для бровса , построения отчета ?
p519446: Для отчетов, вестимо. Усер выбирает набор пунктов из некоторого множества, он может выбрать любое их число. Кол-во выбранных пунктов определяет длину условия вида '(some_id="091523".or.some_id="123407".or. ...)' Когда-то я напарывался на ограничение длины условия именно в АДСе, но не помню, при каких обст-вах и какой версии был тот АДС.
p519446: ЗЫ. Дим, пардон, что ответил с таким опозданием. В форум редко захожу. Если что-то интересно, мыль - всегда буду рад пообщаться.
Dima: p519446 пишет: Для отчетов, вестимо. Ни когда не юзаю фильтра в отчетах. Хожу по индексу. Но это дело хозяйское конечно ;)
p519446: > Ни когда не юзаю фильтра в отчетах. Хожу по индексу. Но это дело хозяйское конечно ;) Вот эта вот хрень: SELECT(cSomeALias) SET ORDER TO 0 // !!! AX_SETSERVERAOF("многабукаф", .T.) // !!! поставить обязательно второй аргумент = .T. !!! DBGOTOP() WHILE !EOF() ... ENDD - выполнится не просто быстро, а ОЧЕНЬ быстро. Даже при ax_EvalServerAOF() = 2, т.е. когда индексы не могут быть заюзаны в полный рост. Главное - set order to 0 перед тем, как поставить AOF-фильтр.
p519446: PS. Индексов ведь на каждый чих не напасёшься....
p519446: Поднимаю тему. Напоролся я всё-таки на какое-то скрытое ограничение. Вот на таком фильтре ax_evalaofexpr() вернёт число 2 (т.е. типа ошибки НЕТ, хотя фильтр и не полностью оптимизированный), но ax_setserveraof() вернёт .F. и при этом ax_error() будет равен 6605 (Advantage Error Code 6605 Client Comm Layer Received More Data from the Advantage Database Server than it was Expecting) NDOC+YEMO="762EL3201304" .AND.(STOK="000055".OR.STOK="000067".OR.STOK="000068".OR.STOK="000056".OR.STOK=" 000057".OR.STOK="000063".OR.STOK="000064".OR.STOK="000058".OR.STOK="000059".OR.S TOK="000062".OR.STOK="000065".OR.STOK="000158".OR.STOK="000159".OR.STOK="000160" .OR.STOK="000080") .AND.(WRPOST+WRCODE="ST300104".OR.WRPOST+WRCODE="ST300109".OR.WRPOST+WRCODE="ST300110".OR. < ... дальше еще ~1500 байт аналогичного дерьма...> .OR.WRPOST+WRCODE="ST200255")
Dima: Не проще ли юзать API клиентского AOF ?
p519446: Оно у мну валит прогу по GPF, в самых разных местах причём. Причину установить не смог, некогда было :(
Dima: p519446 Ну тогда вместо них можно юзать RIO фильтра из SIX , просто переоткрыв базу в другой рабочей области с RDD SIX. Там есть подобный механизм и даже более гибкий. Проверено работает и не медленно.
p519446: Для составления отчетов, когда таблица только читается - да, это выход. За идею спс, попробую.
полная версия страницы