1. Есть ли более подробное описание элементов управления (xbLabelEditRefer, xbReferCaller, xbGrid)?
Стандартный хэлп, уроки не устраивает - там нет этой информации или она ограниченная.
2. Можно ли пользоваться компонентой TBestDataset, не создавая TBObject, аналогично TBObject?
Т.е. обращаться к методам append, edit и т.д.
3.Есть подробно расписанные примеры реализации интерфейса с вызовом справочников?
Уроки в форуме тоже не устраивают.
Денис пишет:
Поясните для чего умножаете на количество пользователей?
Просто прикинул потери рабочего времени для организации.
Цитата
Денис пишет:
Есть подозрение, что если написать плагин, который будет физически удалять все записи в перечисленных файлах, а потом запустить полный пересчет Банка данных по счетам, то получим результат быстрей (с учетом времени работы плагина), чем после индексации (на СП21 без учета времении на индексацию)
Обязательно приму рекомендации к сведению, как выполню - сообщу результаты; кстати насчёт плагина, если делать такой плагин, то нужно расчёт банка данных запускать не в монопольном режиме. Естественно если это возможно...
Результаты таковы:
БЭСТ5 SP 20, к сожалению не было возможности построить банк данных по счетам на SP21..
Касперский выключен был.
В main.dbf 352503 проводок
Сервер у клиента - 2 процессора Intel Xeon по 4-ре ядра 2.33 Ghz, RAM 4 Gb, зеркало SATA по 500Gb, 2LAN x 1000, OC - Windows Server 2003 Enterprise Edition
Расчёт шёл 1 час 45 минут - достаточно быстро, но 1 час 45 миниут х 53 пользователя = 92,75 часа.
Это больше чем две рабочих недели простоя ...
"Типа сервер" у меня - HP Compaq 1 процессор Intel на два ядра 2.8 Ghz, RAM 4 Gb, SATA, 1 LAN x1000, ОС - Windows XP Prof.
Построение банка данных шло 22 часа 15 минут.
В целом - результатами удовлетворён.
Есть одно обстоятельство - я нигде не нашёл есть ли в SP21 изменения по функциям DR и CR?
Сделали ли параметр отвечающий за расчёт по main.dbf или по банку данных и как его вызывать, если сделали?
Денис пишет:
После выхода СП21 (надеюсь) попробуйте сделать индексацию и посмотреть время построение банка данных по счетам. Сутки идет полный перерасчет или за последний месяц? И присоединяюсь к у, расчет банка данных по счетам проходит локально или по сети?
Давай так поступим, я сейчас на сервере клиента запущу полный переасчёт и по результаты сообщу позже.
Считаем локально на сервере.
nordk пишет:
Сан Саныч уже пообещал запрос отключить, а вот почему банк данных столько строится ? Это на базе в 300 тысяч проводок ? Запускаете задачу локально на сервере? В это время еще какие-то задачи крутятся ?
В базе данных сейчас 352503 проводки, это соответствует первому полугодию.
Всё расчёты и первичный, и перестроение запускаем на сервере.
Задач на сервере больше нет, сервер специально куплен только для БЭСТ5. Единственная подозрительная задача, это антивирус Касперского, но по идее, он не должен сильно тормозить.
nordk пишет:
Да, в примитивном случае можно наложить скоб и будет все быстро, но потом у кого то высняется что в 1 случае из 1000 бывает вот такая ситуация, у другого другая и универсальность бывает расплатой за скорость.
Плагин буден уникальным - только для этого клиента.
Цитата
nordk пишет:
Если добавляете строки - используйте ADDREC() - эта штатная функция невидимо от Вас сама заполняет ключевые гуиды.
Эту функцию и используем..., но idmain не заполняется? Может AddRec вызывать с какими-то параметрами, чтобы idmain заполнялся? Но в описании функции не написано, что у AddRec вообще есть параметры.
Цитата
nordk пишет:
Но еще раз повторю - я не системщик, подобные ы лучше бы обсудить на соответствующем форуме, но большого разбега по времени между локальной работой и работой по сети быть не должно....
Спасибо за разъяснения, я тоже не системщик... По крайней мере понятно, где и как можно проводить оптимизацию.
nordk пишет:
Обычно при такой ситуации мы давали системную администратору задачу, чтобы скорость работы по сети не уступала локальной существенно. Не знаю над чем он там колдовал, но в итоге скорость работы что локально, что по сети были примерно одинаковые.
Можно поподробнее, над чем он там колдовал?
И сколько одновременно работающих пользователей было?
nordk пишет:
В свое время Александр Гершанов обращался с вопросом, что у него в базе было около миллиона проводок и мне доводлилось доказывать что харбор умеет работать с таким массивом очень быстро. Так что 300 тысяч для харбора это не размер :)
В функциях которые Вы критикуете, применяется именно скоб и работают они не медленно, а если использовать банк данных, то практически моментально.
Да, Харбор штука шустрая, мне и удивительно, что в базе всего 350000 проводок и такое "проседание" по скорости.
nordk пишет:
Александр я прошу Вас оставить эмоции. Не вижу, чтобы я был с Вами не вежлив.
Может я и погорячился, но я прошу помощи в решении а и не рассчитываю на ответ, а читал ли я про поля.
На будущее - замечание услышал... буду точнее описывать задачу и ситуацию вокруг неё.
Я сюда хожу за решениями вопросов и клиент у меня серьёзный, пусть даже и один. Пока один...
Александр Титов пишет:
Добрый день! 1. IDMAIN лучше заполнить функцией XGUID() (если в БЭСТе). 2. Насчет запросов - с ближайшем пакете сделаем возможность управления (задать вид расчета). 3. По поводу "наложить скоб и выдать результат за пять минут" - пробуйте конечно, но не все так просто...
Спасибо за конструктивный ответ.
Только что, получили результат: отчёт со скобом сформировался за 4-ре секунды !!!
Заметили ещё одну особенность: в случае использования DR и CR на сервере отчёт отчёт формировался за 5-7 минут, а на клиенте более 40 и выключили не дождавшись... Такое ощущение, что алгоритм расчёта функций не использует технологии SQL или использует как-то не полностью.
itman пишет:
Судя по у, можно понять что вы пытаетесь сформировать пакет проводок на основании данных по счетам. Почему харбор а не групповые операции? Что ответил на вашу проблему Региональный представитель?
1. Совершенно верно, есть такая задача - закрытие счетов затрат, да и не только затрат.
2. Харбор, потому что, база большая, 352503 проводки и пользователей 53 человека будет. Хотя для SQL, это не объём должен быть...
3. Региональный представитель настраивает групповые операции, а они в данном случае очень медленно работают.
Но теперь ситуация такая, ошибка исчезла, но объединения не происходит, то есть результирующий запрос выдает только обороты по 2503, а все остальные счета, игнорируются. То есть запросы, как бы выполняются, но в результирующей таблице показывается результат только последнего запроса ???