Отправлено: 07.06.10 13:04. Заголовок: 007.012.003 жуткие тормоза в поиске и при заведении платежек

стояла версия 007.008.000
апгрейднулись до 007.012.003, далее, т.к. база ведется аж с 2003 года то некоторые номера стали двоиться и накладываться... в общем по совету из банка я произвёл архивацию базы... но после этого начались жуткие тормоза. Бухгалтер очень жалуется....
тормоза при быстром поиске платежек, и при набивании-копировании платежек.
смотрел по загрузке проца - доходит до 100%.
индексные файлы NDX убивал... - не помогло,
архив (ARCHIVE) пробовал удалять - тож не помогло.
походу дела всё именно из-за операции Архивирования....

как нить можно это вылечить?

 Отправлено: 07.06.10 13:08. Заголовок: есть мысль что напри..

есть мысль что например после удаления записей из таблиц при архивировании, сберыч не пакует эти самые таблицы (операция упаковка таблиц как в 1С-ке с dbf-файлами), но это такие теоретические предположения.....

в любом случае неплохо бы хоть какой нить вариант решения проблемы :)

 Отправлено: 07.06.10 15:30. Заголовок: printf пишет: смотр..

printf пишет:

цитата:

смотрел по загрузке проца - доходит до 100%

Вот этого не должно быть. В подобном случае пробовал накатить Виндозу "обновлением" - помогает 100%. Shell32 перестаёт вести себя подобным образом и "вздувать" приоритет для К-Б.

 Отправлено: 08.06.10 09:01. Заголовок: на машине стоит сраз..

на машине стоит сразу 5 банк клиентов (доступ через модем).
после архивирования на двух банк клиентов начались тормоза при поиске - ввода букв идёт посимвольно, при этом загрузка проца поднимается до 50% (2-х ядерная машина, то есть по одному ядру идёт загруз на 100%).
и такие тормоза именно на 2-х клиент банках где и было сделано архивирование баз.
на остальных К-Б тормозов нет.

 Отправлено: 08.06.10 09:02. Заголовок: с обновлением это то..

с обновлением это точно не связано, везде поставил 007,012,003 и только на двух К-Б тормоза...

 Отправлено: 08.06.10 20:12. Заголовок: может реессстррр п..

может реессстррр ппоччистиитььь и поновой накатить?

 Отправлено: 09.06.10 14:25. Заголовок: Тормоза после архива..

Тормоза после архивации наблюдал неоднократно на ВСЕХ версиях АРМ начиная с 07.005.00 и выше.
Явный баг в процедуре. Особенно, если база платежек довольно большая (более 3000), а таких клиентов у нас довольно много...

 Отправлено: 09.06.10 14:39. Заголовок: архивацию проводим у..

архивацию проводим у многих клиентов, таких проблем не наблюдали.....

 Отправлено: 10.06.10 11:35. Заголовок: Особенно, если база ..

цитата:

Особенно, если база платежек довольно большая (более 3000)

вот-вот, как раз наша ситуация :)

провёл архивацию на 007.008.000 -- таже ботва, начинает потом тормозить.
но не везде, а вот если выбрать рублевые платежки, выбрать получателя, и потом быстрый поиск -- вводишь буквы ООО и начинаются тормоза, проц грузится под 100%.

Пуська - да мож ваши клиенты не жаловались просто, или платёжек очень мало.

 Отправлено: 10.06.10 11:54. Заголовок: Блин, не вижу коррел..

Блин, не вижу связи. База получателей это USER.DDF - можно попробовать удалить индексы и почистить саму базу от ненужных вхождений. "Справочники - получатели"
Но смущает то, что при архивации она ни коим образом не затрагивается...
Возможен вариант кривого быстрого поиска, м.б. попробовать накатить последнюю версию?
Сделать бэкап, накатить версию,попробовать в работе и ежели не устроит - откатить назад.

 Отправлено: 10.06.10 13:21. Заголовок: я накатывал уже верс..

я накатывал уже версию 007.012.003 поверх на 007.012.003 -- всё тож самое...
поиск какой то тормозной...

w0rkm4n пишет:

цитата:

почистить саму базу от ненужных вхождений.

а что это значит?

рублевые платежки не удаляются никак.

до архивирования кол-ва информации было куда больше и работало всё без Тормозов.

наверно надо было не Архивироваться а устанавливать новый клиент банк, а старый переименовывать и использовать только для просмотра старой инфы.

 Отправлено: 10.06.10 13:53. Заголовок: printf пишет: а что..

printf пишет:

цитата:

а что это значит?

я про "почистить справочник получателей"

 Отправлено: 11.06.10 12:16. Заголовок: там 580 получателей,..

там 580 получателей, построчно удалять времени займет много.
а оптом не удаляется.

а платежек 2617.

чуток почистил - всё равно не помогает, какой то явный внутренний баг.

прикол еще в том что если вводишь данные которых нет в поиске, то буквы-цифры вводятся быстро, тормозов нет.
а если то что находит клиент-банк, то сразу поднимается загрузка проца и начинает поиск тормозит...
по идее - фигня какая то, ведь поиск что так работает, что так -- не важно что ты вводишь... а тормозит тока когда инфа находится.

 Отправлено: 13.06.10 09:55. Заголовок: printf архивацию пр..

printf
архивацию проводим только подсистемы рублевые п/п..и все!
честно, никаких жалоб!
встречалось пару-тройку случаев жутких тормозов (абсолютно не связанных с архивацией) при обновлении версии или при перестройке индексов справочников БИК и SWIFT, порядка 2-3 часов на это уходило...решалось просто - убиением оператора и чисткой реестра...

 Отправлено: 15.06.10 00:27. Заголовок: printf Подтверждаю,..

printf
Подтверждаю, что жалоб на тормоза КлБанка после архивации не поступало. Наоборот скорость только увеличивалась.

Такое ощущение тормоза возникают из-за того, что КлБанк обращается к службам Windows. А те в свою очередь и вызывают нагрузку процессора 100%. Мне например такое представляется, когда настроена какая-то своеобразная индексация в Windows или базы в сети.

Я советую заархивировать все данные не только за прошлый год, но и за этот. А потом удалить файл work.ddf (база платежек) и еще *.ddf с базой плательщиков, но какой точно не скажу, надо искать его экспериментальным путем. Тогда база получится чистая, как будто с нуля ее установили.

ЗЫ 580 получателей - никогда не видел такую гигантскую базу контрагентов

 Отправлено: 15.06.10 15:35. Заголовок: да, я тут провёл тес..

да, я тут провёл тестовую повторную архивацию (до 01.05.2010) вроде как помогло :), теперь стало побыстрее работать :)
спасибо

буду теперь бухам "начистовую делать" :)

 Отправлено: 16.06.10 10:46. Заголовок: не устроило наших бу..

не устроило наших бухов вариант обрезания до мая... им нужен весь этот год.
в итоге одна из баз клиент-банка
было записей в платежных рублевых поручениях - 51849
стало записей - 2025
в итоге при поиске тормозит, и когда нажимаешь на колонке получатель - задумывается.
а до архивации такого не было.

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

 Отправлено: 16.06.10 17:25. Заголовок: printf пишет: и не ..

printf пишет:

цитата:

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

Поверьте, разработчики и не такое могут.
Внутренний уникальный номер документа в базе формировался по примитивному методу... не будем уточнять какому, и через год уникальные номера начинают совпадать.
2 выхода. Обновляйтесь или режьте базу.

 Отправлено: 28.07.10 17:05. Заголовок: Поверьте, разработчики и не такое могут.

Доброе время суток господа и дамы:)))
сегодня абсолютно с такой же проблемой столкнулись, после архивации включительно по 31.12.2009 года, пошли косяки с быстрым поиском! клиенту не обходим он просто, по дате выбирать не имеет желания! кто что еще скажет, примерно кроме наката винды уже все попробывали, ну или почти все!!
буду рад любому дополнению по данной проблеме!???

 Отправлено: 28.07.10 20:30. Заголовок: Sasha911 пишет: буд..

Sasha911 пишет:

цитата:

буду рад любому дополнению по данной проблеме!???

Отзвонитесь завтра на 8-963-279-0065 - проблема решаема.

 Отправлено: 29.07.10 04:40. Заголовок: Отзвонитесь

Уважаемый Mike666, если информация секретна хоть в личку напиши!