Зависание при отборе в Browse

[Андрей]

Наблюдается странное поведение программы в одном месте, не могу понять, что это значит.
А именно - есть форма ввода оплаты абонентами, Вrowse по 3-х уровнему ключу Opl:OrgDataFam.
Соответственно отбор по 2-м верхним ключам, есть Spin поле g:DataOpl (ДатаОплаты), как Range Limit Value и поле g:OrgDgKod, Drop, возвращающий код МестаОплаты как ResetField. Ну в общем все работает: меняем или ДатуОплаты или МестоОплаты содержимое броуза обновляется. Но клиент жалуется, что иногда в этом месте клинит - висит ! Выбирают, например 21.01.16 по опред. месту оплаты и виснет программа ! Приезжаю, проверяю - действительно так. Забираю базу, запускаю на своем компе - все ОК ! Проверяю, под XP (как у клиента) - тоже все ОК ! Ну и как это понять ??? Причем если они открывают лиц. карточки и там заходят во вкладку Оплата, то там все ранее введенные суммы оплаты по отдельному л/с правильно отображаются !

CW 9.1

[kreator]

Вrowse по 3-х уровнему ключу Opl:OrgDataFam.

Мне кажется, где-то здесь проблема. По Вашему сообщению не очень понятна схема данных. Но я бы поставил stop в методе ApplyFilter и ApplyOrder, чтобы посмотреть что там. Может быть на Вьюху не то накладывается.

[Андрей]

Вrowse по 3-х уровнему ключу Opl:OrgDataFam.

Мне кажется, где-то здесь проблема. По Вашему сообщению не очень понятна схема данных. Но я бы поставил stop в методе ApplyFilter и ApplyOrder, чтобы посмотреть что там. Может быть на Вьюху не то накладывается.

Ну это да, Вы правы, зря я описывал подробно схему отбора, там все должно быть нормально. Действительно в броузе есть ФИО абонента, которые прицепляются через 2 родительские таблицы, наверняка если их убрать все будет ОК. Я не понимаю другого - как это у меня все ОК, а на другом компе виснет ! На идентичных базах ! ???

[Игорь Столяров]

Причем если они открывают лиц. карточки и там заходят во вкладку Оплата, то там все ранее введенные суммы оплаты по отдельному л/с правильно отображаются !

Значит операции по БД проходят, а зависание происходит где-то при обновлении списка или окна (например ThisWindow.Reset).
1. Как вариант диагностики - можно добавить программу и папку с БД в список исключений антивируса (если он есть).
2. Проверить нет ли в программе процессов, которые могу выполнить в фоне захват списка.
3. Для WinXP можно сделать вот такую вставочку, где-нибудь при запуске программы:
(если зависание происходит через некоторое время после работы)

Код: Выделить всё

  ! --- Переустановка ограничений GDI Windows ----
  If Int(GetReg(REG_LOCAL_MACHINE,'SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows','GDIProcessHandleQuota',Loc:TypeParam)) < 65000
     PutReg(REG_LOCAL_MACHINE,'SOFTWARE\Microsoft\Windows NT\CurrentVersion\Windows','GDIProcessHandleQuota',0FDE9h,Loc:TypeParam)
  end

4. Можно сделать тестовый вариант программы, расставить везде где только можно в методах вызов процедуры записи в текстовый лог
прохождения выполнения обработки, что бы точно поймать точку зависания. И далее уже по обстановке ...

Действовать так Вам следует я думаю ...

[Ал]

возможно, были разные условия окружения при проверке - у вас на локальном база лежит, у клиента - на серваке?
Просмотрите словаре как спроектированы зависимости между файлами - может где-то "лишние" обновления по ключевым полям идут...

[Ал]

...На идентичных базах ! ???

базы-то боевые копировали от клиента? может там ключи уехали?

[Андрей]

...На идентичных базах ! ???

базы-то боевые копировали от клиента? может там ключи уехали?

Самые что ни на есть свежие. Убеждаюсь, что проблема есть и копирую.
Комп там тормозной, однопроцессорный, расчет идет на порядок медленней, чем у меня, может есть какой нибудь таймер, не успевает View строиться... ? Придется наверно сделать "2 шага назад...", не выцеплять ФИО абонента через 2 связанных таблицы, а записывать ФИО прямо во время ввода оплаты в доп. поле в таблицу оплаты

[kreator]

Всё может быть. И чем сложнее схема, тем отладка должна быть тщательнее (это я про трёхуровневый ключ). Скорее всего что-то не ресетится, или ресетится не так.
Может не в тему. Сталкивался (причём при работе на Firebird) - в буфере вьюхи (???) остаются какие-то записи, при изменении фильтра они отображаются.
Вообще первым делом я бы обновил Clarion.

[Андрей]

Сейчас глянул... а может и не ФИО виновато, оказывается у меня еще и Additional Sort Fields включены аж по 3-м полям (улица, дом, квартира), каждое из своей таблицы STR:Name,DOM:IdDom,Lic:KVARTIRA. Причем Opl->Lic(л/с)->Dom(дома)->Str(улица), т.е разных уровней подчиненности.
Получается - сложное построение вьюхи и на слабом компе виснет ? Надо найти еще более слабый комп, чем у клиента и проверить сею догадку

[Ал]

инфы немного чтобы что-то конкретное советовать, в общем приближении - просмотреть "чистоту" кода в ручных вставках - типа точность позиционирования сразу на нужную запись или на начало нужных периодов и проходы по циклам при переборах/выборках в ручных вставках, гдето можно досрочные выходы поставить и тп, подкрутить если базы поддерживают BUFFER STREAM FLUSH, может гдето есть смысл для удобства и ускорения процесса собирать справочники/промежуточные результаты расчетов и тп. во временные таблицы (in memory)...

[Алексей- Софт-Центр]

Добрый день!
Я бы ещё почистил все темп папки на тормозном компе.
Возможна задержка их открытия при размещении временных файлов.

Алексей