ViewGrid с большим количеством строк

Сортировка (переупорядочивание) зависает для большого количества строк в гриде. Явно там типа курсора, а это очень дорого.

Forums: 

Курсора в EXE нетЧТо может п

Курсора в EXE нет
ЧТо может приводить к проблемам в сортировке ?
Отключи подчитку - есть установка что типа если грид длиннее (не помню) 200 строк то читать его частями
Поставь там 0

Изображение пользователя ipanshin.

Более подробней ,pls, где это

Более подробней ,pls, где это устанавливается?
select @cnt=@cnt+1000
insert into Detailed (No,u,UDN,Lev,Recycable,AccMode,ValueType,IntValue,ValueId,ValueFormat,StringValue)
select @cnt,@@spid,@p1,@lev,0, 12,8,0, 'GatchAct', 'lСписок GatchAct', 'GatchActList'

В клиенте меню Сервис/Настройк

В клиенте меню Сервис/Настройка формы.
Надо отключить буферизацию гридов.

IMHO, если грид больше 300 строк, то интерфейс спроектирован не правильно. Исключение: спецификации документов (списки товаров и т.д.).

Изображение пользователя ipanshin.

Да, спасибо. Помогло, но...С

Да, спасибо. Помогло, но...
Сортировка 10000 строк это порядка 3-4 минут. Да и еще процессор нагружен на 96 процентов. Практически все подвисает. Хотя приоритет процесса normal.

Вообще очень интересно получается. Я называю документ, ну например, 'Связь клиента с абонентом'. Далее в этом документе указываю крутой (м.б. для некоторых не очень)
select
a.ac_id,b.company,a.sub_id,c.name,d.mobile_no from bill..sub_ac a
left join bill..client b on a.ac_id=b.ac_id left join bill..sub_name c on a.sub_id=c.sub_id
left join bill..sub_mobile d on c.sub_id=d.sub_id where a.ended>getdate() and b.ended>=getdate() and c.ended>=getdate() and d.ended>=getdate() order by a.ac_id

Далее cntrl-S и 'выполнить код документа' как пункт из меню дает выборку в грид. Готовая чисто справочная система. Сюда бы кнопку 'Грид в режим редактирования'. Вот тебе и инструмент администратора.
Причем смотрите, таких select м.б. несколько. Тогда в рамках одного документа будет несколько гридов. В общем здесь употребляется все, что допустимо в query analyzer с ограничением динамического sql <=4000 символов для sql7 ну и еще ряда ограничений.

Блин, проектировщики были GreenPeace members.

А я как старый рыжий лис
Слюной истек, уныл, прокис...
Тот виноград зеленый не достать
опять в GreenPeace писать,писать,писать?...

С уважением
Игорь

p.s. Кстати я нашел место, где вставить доп.параметр для процедуры. Это callselect
-- нужен еще хотя бы один параметр передаваемый в операционную процедуру
/* -- вставить в CallSelect

declare @par1 int
select @par1=(select IntValue from ProcParam where u=@@spid and UDN=@UDN and No=0)
if @par1 is null exec @ret=@ProcName @UDN
else exec @ret=@ProcName @UDN,@par1
*/
Нужно одобрям Димы.

ПРивет Идея интересная, я

ПРивет

Идея интересная, я с ней почти согласен
Надо только придумать как это сделать совместимо со старым кодом
А то может так оказаться что CallSelect попытается вызвать процедуру с двумя параметрами когда она понимает только один

Я сейчас поразмышляю

Я придумалИтак если в ProcPa

Я придумал
Итак если в ProcParam есть параметры с преподпределенными именами
IntPar1,MoneyPar1,FloatPar1,StringPar1,DatePar1
то вызывается процедура обработки viewgrid со вторым параметром указанного типа (пять случаев)

Если таких параметров нет то все работает по старому, вызывается процедура с одним параметром

Можно добавить и второй параметр но тогда получается слишком много вариантов (5*5=25) изза типов. Я же видел процедуры (ViewRepLogin) с тремя параметрами

Может быть сделать строку динамически ?

Изображение пользователя ipanshin.

Ну дык, why not?предлагаю за

Ну дык, why not?
предлагаю засунуть все 5 в одну строку с No=0(по моему он не используется) и формировать список параматров типа
if @MoneyVal is not nul set @sql=@sql+','+convert(char,@moneyVal)
А потом все выполнить.
Ну и естественно, если все null, то по старому
после выполнения надо только null восстанавливать в procparam.

Вот объясните мне на фиг нужны

Вот объясните мне на фиг нужны сложности с волшебными именами параметров и прочее.

Все делается гораздо проще. ProcParam надо разбирать не в CallSelect, а в процедуре формирования выборки для ViewGrid!!!
Даже если эта процедура строиться динамически (см. здесь), то я не понимаю, в чем может быть сложность для задания порядка сортировки. Вставь в динамический код поиск и разбор строки из ProcParam c симпатичным тебе ValueId (например, 'OrderBy') и все.
Одно из ключевых свойств системы, то что вызов процедуры строго специфицирован для каждого типа обработчика, а вы это хотите порушить.
Подумайте хорошенько.

Изображение пользователя ipanshin.

Смотри, у меня есть первоначал

Смотри, у меня есть первоначальный select ... into rezset ... order by

ViewGrid указывает на proc такого плана

select ... from rezset здесь мне надо order by из первого select

ессно, я его беру не из procparam, а из общего поля кода. Это без проблем.
Единственная проблема, что длина динамического sql ограничена и там разбор всякий дороговат пока.
Поэтому, я не вижу причин отказываться от изменений, если все старое будет работать. причем это относится только к операционным обработчикам, а не класса. Зато ограничение для операционных обработчиков - только один параметр будет снято. Не хочешь - не пользуйся. Но почему ограничивать себя - и так я уже не курю, не пью, не ... Еще и процедуры только с одним параметром?
Не согласен. Дима делай быстрей. Это не долго.

Изображение пользователя ipanshin.

Хочу уточнить. Достаточно толь

Хочу уточнить. Достаточно только еще одного параметра типа char. Остальное от лукавого. В этом char-е и будем передавать петушиные имена для procparam или чего еще.

Ни чего не понял ...Что за о

Ни чего не понял ...
Что за общее поле кода? Если он доступно, то почему не брать order by прямо из него?

делайте как хотите только оставтьте возможность путем отмены define получить классическое ядро.

Сейчас буду брюзжать:
тут все очень сильно ругаются на всякие изыски предшествующих разработчиков. Возмущаются, например, что доп. колонок всего 16, они хреново двигаются и сортируются. А их вообще не должно было быть! Это, точно так же, сделанная наспех доработка по частной задаче, без оценки последствий.
Или вот еще пример, управление форматом страницы через задание значения в поле OldInt в Deteailed c No=0. Что логично и прозрачно?
IP и DT продолжают дальше идти по пути cheap&dirty. Это путь разрушения.
Есть спроектированный и отлаженный механизи передачи параметров в обработчик через ProcParam, который позволяет передать ЛЮБОЕ число параметров. Так нет, обязательно надо сделать частный случай. ProcParam c No=0 это загаловок набора параметров. В частности StringValue отображается как загаловок окна. Давайте эту запись использовать только для описание параметров набора в целом. Иначе никто не сможет подхватить знамя, выпашее из рук. Т.к. логика предложенного решения извращена.

Может считать меня реторградом, палкой в колесе прогресса, но БАБА-ЯГА ПРОТИВ. :evil:
Если такие модификации будут и дальше проходить, то я перестану поддерживать СР для новых версий ядра. В ядре и так полного загадочных глюков, а вы их собираетесь множить.

Изображение пользователя ipanshin.

В общем, ты прав. Спешить не н

В общем, ты прав. Спешить не надо. Надо думать. Но это не изыски, а необходимость.

IP и DT продолжают дальше идти по пути cheap&dirty.

А вот это не хорошо. Мой путь очень трудный и дорогой так как касается дальнейшего развития.
Почему автоматически подхватывается один параметр у операционной процедуры и не подхватывается список? Пусть через procparam, через еще что либо, но я должен создать

create procedure xxx @udn int, par1 varchar(111) as
закинуть в procparam par1 и не думать о его выковыривании из procparam в процедуре xxx

Хотя м.б. я и не прав. Надо подумать. Блин, но SQL же позволяет список параметров? Почему же мы кастрируем операционный обработчик до одного параметра?

IP и DT продолжают дальше идти по пути cheap&dirty.

Чей же путь чище и дешевле?

вызов процедуры строго специфицирован для каждого типа обработчика

Уточняю. Здесь я говорю об операционных обработчиках(OperProperties), а не обработчиках классов.

Я согласен с ИгоремЯ помотрю

Я согласен с Игорем
Я помотрю насколько легко сделать чтобы параметров было много

Для Сергея:
Путь у тебя есть процедура которая получает параметры
Если у нее нормальные параметры в смысле SQL, То ее можно использовать как для Gird, так и для Crystal Report.

Если же процедура внутри себя пытается читать параметры из ProcParam да еще по @@spid, то понятно использовать ее в Crystal Report И ни одном внешнем средстве нельзя.

Можно конечно написать 'переходник' , но все таки...

1. Предлагаемое решение позвол

1. Предлагаемое решение позволяет добавить еще только один параметр строго определенного типа (varchar). Через месяц встанент вопрос о третьем параметре. И так до бесконечности. Потому что решение не универсально.

2. Я не вижу существенной разницы, между "ковырянием" в ProcParam, и ковырянием в строке. По своему опыту могу судить, что нормальных функций для синтаксического разбора строк в Transact-SQL нет.

3. Все описание ViewGrid содержится в строке Detailed, за чем тогда сюда припелетать еще ProcParam. Двайте сделаем клаузу ^param=, в которой будут задаваться доп. параметры (или указывать список параметров в OldString, но лично мне по душе клауза).

select @cnt=@cnt+1000 
insert into Detailed (No,u,UDN,Lev,Recycable,AccMode,ValueType,IntValue,ValueId,ValueFormat,StringValue)
select @cnt,@@spid,@p1,@lev,0, 12,8,0, 'GatchAct', 'lСписок GatchAct', 'GatchActList^param=''order by Field'',342,''20040131'''

Тогда вызов будет такой:
execute('exec GatchActList @UDN, ''order by Field'', 342, ''20030131''')
Что скажите?
Кто знает, какая макс. длинна строки, которую клиент может передать при вызове CallSelect?

Изображение пользователя st.

Полностью поддерживаю Серегу.

Полностью поддерживаю Серегу. Перефразируя известную поговорку, "Мы не настолько богаты, чтобы использовать дешевые решения". Тем более, речь о ядре.
P.S. По поводу длины строки. Помню, что еще в MSSQL 6.5 я передавал в процедуру параметр типа text. Типа

create procedure Test
  @Str text
as
begin
...
end

P.S. По поводу дли

P.S. По поводу длины строки. Помню, что еще в MSSQL 6.5 я передавал в процедуру параметр типа text.

CallSelect вызывает EXE, поэтому вопрос был о том, какой длинны параметр он может передать. Если в клиенте описано что-то типа char[32] (мах длина идентификатора в 6.5), то полный привет ... :(

Изображение пользователя ipanshin.

select a.name,b.name,c.name fr

select a.name,b.name,c.name from sysobjects a
left join syscolumns b on a.id=b.id
left join systypes c on b.xusertype=c.xusertype
where a.xtype='P' order by a.name,b.colorder

Этот select вытаскивает все о списке параметров и их типов для всех процедур. Так что построить динамический запрос для списка параметров не так уж сложно.
Вытащил параметры - определил их количество и тип и из ProcParam сформировал список уже фактических параметров для процедуры в соответствии с их типом. Если int , то из IntValue, и т.д.

С уважением
Игорь

2. Я не вижу существенной разн

2. Я не вижу существенной разницы, между "ковырянием" в ProcParam, и ковырянием в строке. По своему опыту могу судить, что нормальных функций для синтаксического разбора строк в Transact-SQL нет.