v7: Множественный отбор в журналах и справочниках 7.7 заменой запросов SQL #210738

Зацените разработку (приложен тестовый пример, который можно скачать). Порядок установки - в readme.txt. Позволяет делать отбор сразу по нескольким (а не по одному) реквизитам в обычном (не только общем) журнале документов. То есть, более полно использовать возможности отбора, присущие языку запросов SQL.

Зацените разработку (приложен тестовый пример, который можно скачать). Порядок установки - в readme.txt. Позволяет делать отбор сразу по нескольким (а не по одному) реквизитам в обычном (не только общем) журнале документов. То есть, более полно использовать возможности отбора, присущие языку запросов SQL.

Не сердитесь на меня, за то, что я поднимаю ветки, я всего лишь бот. Все претензии к моему автору - Волшебнику. Мои сообщения - это его сообщения.

Жаль, сто на для ДБФ...

Аналогично реализуется отбор в справочниках.

хочу в дэбэээээф... (ушёл плакать)

Ну вот оказывается никому не нужно :-(

Нужно! Ты коротенько поясни смысл ИспользоватьСписокЭлементов?

Или как оно там? Тестил по сетке?

SQL же, а там по барабану, сетка или локально. Лана пойду справочники мутить. Там должно быть интересно: полный отбор по любым критериям, включая признак пометки на удаление... Быстрый подбор можно также наверное реализовать...

имел в виду типо реальной работы, когда все что-то делают

вещь нужная спасиба попробую

Это отбор в форме списка справочника через АДО

Жаль, что это сделано не лет 5-6 назад

в Демо базе делаю отбор по Товар - Киндзмараули В итоге две строки. устанавливаю курсор на вторую строку. если прокрутить колесико мышки вверх то оба документа исчезают из журнала

На реальных пользователях пока не тестил. Но они очень настаивали на отборах и я уже запарился объяснять что 7.7 этого не поддерживает. :-)

ОК. Попробую на средней (2 Гиг) базе локальной скоро. На пользователях - боюс :)

Оказалось кстати что ничего сложного: подменная DLL и фтыкание условий в предложение where

Молодец короче!

Я ж знал, просил людей: "ну сделайте полноценный отбор"

Ну да, конечно. Сначала на тестовой базе... Может и мне рабочую базу развернуть :-)

Слухай, а патчер куда надо? В Бин переносить? Говорит не найден Бкенд.длл

Короче работает! Офигеть!

глЗначениеОтбора - зачем?

А если 1С++ прикрутить и выкинуть АДО? тогда, в принципе, для ДБФ проблем не должно быть?

Думается, что так

попробуй

+ потом расскажешь :)

в выходные сделаю, только, фишка одна - в КЗ не буду ничего писать, просто потестирую и все

ветку тока заведи, или эту апни

о результатах скажу...

Там в readme.txt я все расписал... Юзал пока отлаживался, забыл стереть.

Вот же блин. И какого фига у нас в Компании софт должен быть лицензионный... Так и тенуться руки лицензионное соглашение нарушить

А там запрет на изменение двоичного кода что ли?

А почему только для общих реквизитов? Графу отбора хочу.. :)

модифицируешь код системной 1С кой dllки... Врядли 1С обрадуется ... Может и предяъвить, ИМХО

ламеры, да сделайте любой свой view и юзайте....

Для 1С++ уже года 2 назад как написал журнал с любым отбором

Хде ссылка? А то ведь я тож Windows Vista уже лет десять тому написАл

acsent.nm.ru

37. Он ведь не динамический... Динамический тока я писал.

Другое дело :) Ссылку в студию

Для ДБФ тоже есть АДО... ...

На основе ТП очень даже динамеческий (но ему конечно нет еще 2 лет)

41. Смотри в проклабе по нику matreya, много лет назад выкладывал упрощенную версию (без использования ado).

43. Что такое ТП?

по теме топика :)

Где мы были несколько лет назад? :-)

Так это мой же код! :-)

Только уважаемый romix не рассказывает к чему может привест подобная подмена с точки зрения производительности в случае указания конкретных индексов.(index=) Ну а вообщем то это решение(полное с доп. индексами по отбитраемым полям) есть у Softpoint.

Вообщем проверьте решение romixa на больших журналах и сами все поймете. В случае если в доп. отборе участвует доп. реквизит большой размерности(например строка 20 символов) это может быть для системы вообще смертельно.

Хотя конечно если ромикс все эти ньюансы учел то респект мой и уважуха.:)

Дополнительно индексирование в скобочках можно указывать, я не против. Так наверное будет даже лучше. Спасибо за подсказку. Можно, я думаю, даже очищать это поле - тогда MS-SQL сам проставит в соотв. со своими внутренними счетчиками требуемые индексы. Что же может быть "смертельно опасного" в модификации условия в SELECT? Это безопасный оператор, т.к. он всего лишь читает данные из таблицы по условию. Подбор слов "смертельно для системы", когда речь идет о всего лишь понижении скорости - это чОрный пиар что ли? Или это демонстрация умелого использования методики медицинского гипноза/НЛП заказчика с целью развода на деньги? :-) Пожалуй, я немного изменю DLL, чтобы можно было заменять полный текст запроса - тогда каждый учтет что он хочет учесть...

>>чтобы можно было заменять полный текст запроса SELECT изменить на DELETE :)

Лучше INSERT, это, вообще, по теме будет. Только вот куда потом 1С девать :)

Да, да Ромикс, измени И со справочниками бы то же самое сделать, не забудь :) ЗЫ. Еще не тестил на большой

Для эффективного отбора по нескольким реквизитам нужен дополнительный индекс. Ты его тоже будешь компонентой создавать?

Было бы идеально. Когда ждать ?

А со справочниками - 1с++ идеально работает. ИспользоватьСписокЭлементов(СписокВыбораВзятыйИз1СРР); 49 000 записей по установленным фильтрам (6 штук) менее чем за 0,1 сек выбирает

А ведь неудобства при вводе нового элемента есть, напрмиер Как разруливаешь?

В моем примере - в таблице 1SJOURN находятся дополнительные "Общие" реквизиты с установленной галочкой "отбор" (только тогда они хранятся в 1SJOURN). К ним 1С-ка уже создала индексы: По одному реквизиту, видимо, прокатит стандартный индексированный отбор. По второму и последующим реквизитам отбор будет без индекса, но это тоже вполне штатная ситуация в SQL. Например, во многих случаях по одному контрагенту не так много документов за период... Если же будет проблема с включением тормозов, то придется уже что-то думать, или приобретать более общие решения.

Сейчас мысли в кучку соберу...

А есть ли возможность вместо слова WHERE далать подставу нужного текста ? Например : Вместо WHERE подставлять : LEFT OUTER JOIN DT12345 as Документ (NOLOCK) ON Документ.ID=_1JOURN.ID WHERE Документ.SP67890='xyz' ???   вот хотябы так и тогда вообще все вопросы по тому где лежат реквизиты документов журнала отпадают  :-)

Да, щас будет

Где скачать ?

Однако попробуй на реальном объеме Я мучался - ничего невозможно делать, искать, проводить доки

+ В смысле ДИКО тормозит

Ну да. Я это для ...

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

1) Полностью переписал компоненту, чтобы не требовался явный патч. Полный перехват SQL уже делает внешняя компонента (патч не требуется). 2) Теперь можно заменять SQL-запросы целиком: Таким образом, можно заменить несколько (до 200) шаблонов запросов. 3) В тестовый пример добавлен случай отбора по "не помеченным на удаление" документам. 4) В справочнике добавлен подбор по первым буквам наименования (чтобы отображался не весь справочник, а только те элементы, наименование которых начинается с указанных букв (можно не по первым - тогда % - метасимвол).

Тестовый пример (ссылка изменилась) можно скачать здесь:

Может, у тебя был включен лог (журналирование), а он притормаживает. И в реальной работе совсем не нужен. В любом случае, я сейчас перехватываю (внешней компонентой, а не патчем) единственную функцию SQLPrepareA, остальные не трогаю.

Жуткое качество кода компоненты

(79+) модуль uList просто шедевр :-) да и использование критических секций в незащищенном коде - прикольно

чтобы не выглядело просто злорадством, рекомендую: 1) выкинуть ужас в виде класса TList (кстати, никогда не надо давать пересекающиеся со стандартными классами идентификаторы). Использовать TList :-) только из Classes. Попутно избавляемся от ограничения в количестве подмен. 2) Причина тормозов помимо всего прочего в поиске заменяемого запроса перебором. Использовать простейшую дихотомию. 3) Критические секции обязательно оформлять в try/finally 4) Заменить оригинальный :-) способ финализации g_sz на if Assigned(g_sz) then FreeAndNil(g_sz) 5) Подозреваю, что raise в компоненте покажет не сообщение, а обвалит 1С. Все raise заменить на сообщения с соответствующим маркером 6) InitializeCriticalSection ты делаешь, а освобождать кто будет? When you have finished using the critical section, call the DeleteCriticalSection function.

Спасибо... Сейчас все проверю...

1,2) Чтобы не париться, поюзал TStringList и его свойство Values      g_sz.Values[HexEncode(g_OldSQL)]:=g_NewSQL; Функция HexEncode - просто переводит строку в шестнадцатеричный формат (чтобы ее можно было использовать как ключ в TStringList). 3)   Не согласен - это где такое написано? Может быть, у Рихтера? Но там такого нет. 4) Сделал. 5) Неверно - 1С-ка не падает в моем случае при Raise, т.к. есть обработчик:  try Пользоваться не Raise, а устаревшими заменителями в виде кодов возврата - зло. 6) Сделал. Хотя винды вроде сами освобождают все при закрытии 1С-ки.

Обновил файл в . Пример теперь содержит поля отбора в самой форме журнала.

EnterCryticalSection(SomeSection); raise Exception.Create('тут какой то твой код вызвал исключение'); LeaveCryticalSection... секция осталось залоченой. ps Рихтер твой код писал? тогда я не буду критиковать

А, понял. У меня щас так:

ты гонишь. try  EnterCriticalSection finally  LeaveCriticalSection end

А есть разница?

угу. Только мне надоело

Из разговора по аське я понял что в у меня все правильно.

Забавный диалог. :) То romix - не понимаю твоей мотивации. В чем смысл давать неподготовленные советы? Причем дело в данном случае исключительно с точки зрения професионализма. Подумай сколько людей с некорепшими умами ты можешь подвести своими неподготовленными и непродуманными советами.

Сорри, очепятка. "Некорепшими" -"неокрепшими"  ;)

- сложно сделать "последнее доброе дело" ? - критикуешь - предлагай. Есть что конкретное - обсуди с romix. Если есть шанс родиться чуду - пусть оно родится. Если считаешь себя "профессионалом" - помоги. Не можешь/не хочешь - ну, тут медицина бессильна...

нихрена ты не понял. Водитель, который включает поворот только если сзади за ним кто-то едет, а в остальных случаях просто поворачивает - хреновый водитель. Тоже самое с программистом. Как только пишешь код создания объекта (выделения/блокирования ресурса) сразу же надо писать его освобождение. Поэтому если будешь писать такой код, смело показывай его только 1С-никам. Дельфисты тебя запинают (даже если простят авторское :-) оформление проекта)

Я сам неокрепший, поэтому прошу поконкретнее, о чем это вы? Да и я не уверен, что вы сами щас что-нибудь удивительное не скажете (если конечно дело не ограничится дежурными фразами для НЛП-гипнотизирования клиентов). Я вроде все исправил - Raise точно не буду "исправлять" т.к. это не ошибка, а стиль такой. А с блокировками мы вроде по аське договорились, что я прав. Т.е. конструкция в - правильная и безопасная. Насчет "утечки" DeleteCriticalSection - я это исправил, так что мимо. :-) Да и она безопасная - винды при закрытии сами все чистят. Хотя я бы на месте Билли ругался в такой ситуации (выдавал исключение), т.к. стиль действительно нарушается, и следуя ему легко пропустить настоящую ошибку.

То 95. Поконкретнее - да насчет индексов куда уж конкретнее! На больших объемах сервак у тебя ляжет. У одного из использующих уже такое было.

Вы написали про "забавный диалог" и что я даю "неподготовленные, непродуманные" советы людям с "неокрепшими умами" . Вот мне и хотелось бы выяснить, о каких именно моих "советах" в этом "забавном диалоге" идет речь, и в чем же они с моей стороны неверные. Вы меня случайно ни с кем не обобщаете? :-) Насчет индексов - сейчас у меня поддерживается полная замена SQL-запроса, и все желающие смогут добавить что им нужно по своему желанию.

Т.е. сейчас возможность использовать индексы поддерживается (ничто этому не препятствует).