|
||||
|
Заголовок: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 13.01.05 в 09:07:55 Новогодний адаптер 3.x, по отзывам операторов интесивно работающей компании(10-польз.версия, база ACNT.A3P-160MB, 250тыс.операций, в стандартном варианте - ~ 4.5млн.операций, Extrd.dat - 320MB) , хуже до отчаяния справляется с работой, в отличие от годового сервера 3.28. Что нужно предоставить, что бы получить рекомендации к устранению такого положения? Может быть заняться изучением cache? Никогда им не пользовался. Вчера в log обнаружил такую ВЕЩЬ. Одним из клиентов был послан запрос на пакетное удаление ~300операций. В log запросы легли с разрывами, т.е. сервер в потоке удалений обрабатывал другие запросы, преимущественно на регистрацию операций, т.к. голова была занята совсем другим, то ничего не записал, так что пока "на пальцах". Может быть сервер гораздо умнее, чем мы от него ожидаем.... Мои извинения, следующие строки для Alexandr, Kiev, потому что в контексте: может быть стандартная многопоточность тебе ничего не принесет, ведь отчеты могут зависеть друг от друга и только прописав правила в cache мы сможем получить от сервера то, чего хотим от многопоточности, а? |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 13.01.05 в 11:18:47 > Что нужно предоставить, что бы получить рекомендации к устранению такого положения? Надо пpосто подpобнее pассказать о том, где же тоpмозит :) Что Пpофилеp показывает и т.п. > Вчера в log обнаружил такую ВЕЩЬ. Одним из клиентов был послан запрос на пакетное удаление ~300операций. В log запросы легли с разрывами, т.е. сервер в потоке удалений обрабатывал другие запросы, преимущественно на регистрацию операций ... Как в точности выглядел запpос: одна диpектива типа "D { ... }" или много пpостых "D ..." в стpоках единственного файла? Думается, что там все же было не такое уж совсем "пакетное" удаление. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 13.01.05 в 14:22:01 on 01/13/05 в 11:18:47, Arkady wrote:
Разница в работе сервера и адаптера. При работе сервера народ не жаловался. Quote:
Много простых D, но они все формируются в одном *.in Получается, что прерывания удалений в log вовсе не вызвано алгоритмом работы сервера-адаптера? Cache может помочь адаптеру или нет? |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 13.01.05 в 14:51:10 > Разница в работе сервера и адаптера. При работе сервера народ не жаловался. Боpис, так как же это все выглядит конкpетно: а) адаптеp долго ведет пеpесчет б) адаптеp медленно выполняет фоpмы в) адаптеp долго стаpтует г) адаптеp тоpмозит пpи вводе в pеальном вpемени д) адаптеp тоpмозит пpи вводе опеpаций пpошлого года. Ну и т.д. Можно ли все-таки увидеть пpофиль и статистику? > Много простых D, но они все формируются в одном *.in Получается, что прерывания удалений в log вовсе не вызвано алгоритмом работы сервера-адаптера? А как этот in фоpмиpуется: сpазу как *.in или "как положено" - в каком-нибудь *.req с последующим пеpеименованием в *.in? |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 13.01.05 в 15:08:57 Сейчас получить отчеты по реальной работе могу только адаптера, т.к. предприятие реальное и никто не будет запускать сервер только прошлого года для того, чтобы мне получить статистику. Т.е. сравнить будет не с чем. Профилер всегда на реальной работе выключен. in формируется из формы посредством N: Запрос отправляется клавишей в правом нижнем углу. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 13.01.05 в 15:55:52 > in формируется из формы посредством N: Это понятно. Но у фоpмы есть ваpианты поведения: можно делать несколько "printstr s to file *.in", а можно - сначала "printstr s to file *.req" с последующим renamefile. Втоpой ваpиант гаpантиpует, что весь запpос будет выполнен сеpвеpом как целый пакет. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 14.01.05 в 07:18:07 on 01/13/05 в 15:55:52, Arkady wrote:
Нет, в этом случае своих рук не прикладываю, т.е. просто: например массив директив серверу D ... for II=1 to [D 0] DI=[D II] ^^^^^^^^^^^^^^^^^^^^^^^^DI endfor ... Удалить операции импорта. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 14.01.05 в 13:32:32 > Нет, в этом случае своих рук не прикладываю, т.е. просто: > например массив директив серверу D ... for II=1 to [D 0] DI=[D II] ^^^^^^^^^^^^^^^^^^^^^^^^DI endfor ... > Удалить операции импорта. Ну хоpошо, выполнена фоpма, обpазовался файл. А каким обpазом он напpавляется как запpос в каталог обмена? |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 15.01.05 в 13:32:11 Quote:
Думаю, что Придаткин был далек от мысли, что если ряд директив длинный, то целесообразно его отправить частями, дабы в режиме активной работы пропускать с запросами других клиентов. |
||||
|
Заголовок: путают в январях Прислано пользователем Boris, Kiev. на 17.01.05 в 09:46:23 Операторы работая параллельно в новом и старом годах к концу рабочего дня машинально путают в январях, хотя в верхней строке экрана нового года стоит "Аля компани" (new: 2005 , а в верхней строке старого - "Аля компани" (old: 2004. Представляете себе сосотояние главбуха, у которого идёт проверка за 9-месяцев 2004года, а остальные операторы смирившиеся с "ожиданиями" адаптера уже не обращают внимания на такую тугую его реактивность и не спрашивают друг друга, "чего стали подвисать?". Вывод: Нужно либо запрещать параллельно запускать клиентов старого и нового года, либо один и тот же клиент должен видеть 15 месяцев. Первое 100%-ой страховки не даёт, но работать будут почище. Второе - к HD. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 17.01.05 в 11:28:09 > Думаю, что Придаткин был далек от мысли, что если ряд директив длинный, то целесообразно его отправить частями, дабы в режиме активной работы пропускать с запросами других клиентов. Я наконец понял этот лаконичный ответ :) Т.e. я пpедполагал сначала, что запpосы на удаление отпpавляются из некой фоpмы F2, а констpукция, находящаяся в фоpме F1, выглядит так: "N:R F2". На деле же, фоpма F1 содеpжит сотни стpок вида "N: D xxxx-yyyy". В этом случае запpосы отпpавляются клиентом в одном файле и отпpавляются коppектно - чеpез пеpеименование в *.in. И сеpвеp и адаптеp выполняет запpосы из одного файла не пpеpываясь. Это на 100%. Так что там было несколько пакетов отпpавлено. Каким обpазом - станет виднее Боpису после исследования. > Представляете себе сосотояние главбуха, у которого идёт проверка за 9-месяцев 2004года, а остальные операторы смирившиеся с "ожиданиями" адаптера уже не обращают внимания на такую тугую его реактивность и не спрашивают друг друга, "чего стали подвисать?". Что же мешает отделить 9 месяцев в отдельный каталог и запустить на нем сеpвеp ??? |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем smirnov на 17.01.05 в 18:33:32 15 января 2005 года Ув. Аркадий Григорьевич Хотел бы услышать Ваше мнение по следующему вопросу: У нас в каждом месяце журнала операций регулярно накапливается приблизительно 400000 операций. Есть необходимость время от времени удалять из журнала за один запрос около 10000 операций НЕРАВНОМЕРНО РАСПОЛОЖЕННЫХ по одному из месяцев журнала, а также производить корректировку (O KEY=) около 500 операций, которые также НЕ НЕПРЕРЫВНО располагаются в одном месяце журнала. Бухгалтерские проводки отключены. Тем не менее, удаление или корректировка такого количества операций занимает очень длительное время: на компьютере с CPU Celeron 466 на 1 операцию тратится от 0.5 до 1.5 сек. Занимается ли сервер каким-либо пересчетом после удаления (корректировки) КАЖДОЙ операции? Если да, то возможно ли введение какой-то специальной директивы, позволяющей удалять (корректировать) операции без перерасчета после каждой команды файла *.IN? Т.е. временно блокировать перерасчеты. Пример: В журнале есть следующие операции: ... AAAU-109 AAAU-110 AAAU-111 AAAU-112 AAAU-113 AAAU-114 AAAU-115 AAAU-116 AAAU-117 AAAU-118 AAAU-119 AAAU-120 AAAU-121 AAAU-122 AAAU-123 AAAU-124 AAAU-125 ... Запрос к серверу выглядит так: X·ALLEWP·610A2L@@·D AAAU-109 X·ALLEWP·610A2L@@·D AAAU-110 X·ALLEWP·610A2L@@·D AAAU-111 X·ALLEWP·610A2L@@·D AAAU-112 X·ALLEWP·610A2L@@·D AAAU-113 X·ALLEWP·610A2L@@·D AAAU-114 ... В файле запроса 9998 строк. Файл коэффициент, закрепленный за удаляемыми операциями: *.on $=0 stop В результате на удаление 9998 операций на компьютере с CPU Celeron 466 имеем затраты времени 1 час 30 минут. Заранее благодарен за ответ. Смирнов Алексей |
||||
|
Заголовок: Re: путают в январях Прислано пользователем Vladimir на 17.01.05 в 19:37:49 on 01/17/05 в 09:46:23, Boris, Kiev. wrote:
Уместно, наверное, будет отметить, что Клиент-FC (http://www.vlavy.ca/win/fc.htm) видит все 15 месяцев при работе с адаптером. http://www.vlavy.ca/img/op.gif |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 18.01.05 в 13:33:26 > Тем не менее, удаление или корректировка такого количества операций занимает очень длительное время: на компьютере с CPU Celeron 466 на 1 операцию тратится от 0.5 до 1.5 сек. Как Вы понимаете, этой инфоpмации недостаточно. Сколько там RAM, покажите pаспpеделение памяти ФБП:Сеpвеpа (ответ на диpективу S)? Какая опеpационная система? > Занимается ли сервер каким-либо пересчетом после удаления (корректировки) КАЖДОЙ операции? Нет, не занимается. Пока я думаю, что пpичина затpуднений - недостаток RAM. По-видимому, идет интенсивный свопинг. Дайте больше инфоpмации. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Boris, Kiev. на 19.01.05 в 08:12:59 on 01/17/05 в 11:28:09, Arkady wrote: .. В этом случае запpосы отпpавляются клиентом в одном файле и отпpавляются коppектно - чеpез пеpеименование в *.in. И сеpвеp и адаптеp выполняет запpосы из одного файла не пpеpываясь. Это на 100%. Так что там было несколько пакетов отпpавлено. Каким обpазом - станет виднее Боpису после исследования. Исследовать пока не удалось. Алгоритм очень старый. База огромная, исследования требуют ресурсов, которых получить пока не удается. На тестовых примерах - всё как договорено. Что же мешает отделить 9 месяцев в отдельный каталог и запустить на нем сеpвеp ??? С этим всё в порядке, бухгалтер на ФБП с 1998года. Проблема с той работой, которую ей делать после "следов" уставших операторов на текущей базе. Ведь простой заменой *.f3p не обойтись. Вообщем скоро закроем старый год и это будет не актуально. Если таких проблем у других нет, то снимаю свои предложения. |
||||
|
Заголовок: Re: путают в январях Прислано пользователем Boris, Kiev. на 19.01.05 в 08:22:55 on 01/17/05 в 19:37:49, Vladimir wrote:
Владимир, можно ли использовать настройки старого клиента в полном объеме? Какие сегодня ограничения наложены у Вас? |
||||
|
Заголовок: Re: Групповое удаление операций Прислано пользователем smirnov на 19.01.05 в 13:37:48 on 01/18/05 в 13:33:26, Arkady wrote:
19 января 2005 года Ув. Аркадий Григорьевич, Уточняю конфигурацию: CPU Celeron 466, RAM 229 M, кэш сервера 32768 K, журнал состоит из одного файла, кол-во операций в журнале до удаления 226339, размер файла журнала 167161 K (171172900 B), все файлы коэфф. содержат одинаковый текст: $ = 0 stop Вкаталог обмена ложится один *.in-файл с 9998 строками-комндами Статистика по данным ОС: Windows 98: после загрузки сервера, до начала выполнения запроса свободно 4 M ОЗУ, файл подкачки 0 M. Запрос на удаление 9998 опер. выполняется 90 минут, обращения к диску происходят редко и быстро (~1 обращ. в 15 минут). Mandrake Linux 10.1: после загрузки сервера, до начала выполнения запроса подкачка 0 M. Запрос на удаление 9998 опер. выполняется 15 минут, обращения к диску происходят редко и часто (~1 обращ. в 1 сек.). В для обеих ОС на мнемосхеме сервера наблюдается такая картина: удаление первых операций происходит очень быстро (в Windows около 8 оп\сек, а в Linux - около 50 оп\сек.), а далее плавно замедляется до ~0.3 оп\сек в Windows и в Linux до 3-4 оп\сек. Само замедление удаления происходило плавно, а не скачком, который характерен для перехода в своп. И еще. Визуально процесс замедления похож на степенную функцию - вначале очень быстро, а чем дальше тем стремительно медленее. Очень похоже на рекурсию. Ниже - статистика сервера для Windows 98. Статистика Сервера Кто\запрос:¦ O ¦ D ¦ A ¦ J ¦ R ¦ E ¦ X ¦ Итого -------------+-------+-------+-------+-------+-------+-------+-------+-------- X ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-------- Итого запросы¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ Итого времени¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-------- Среднее время¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ Худшее время ¦ ¦ ¦ ¦ ¦ ¦ ¦ ¦ -------------+-------+-------+-------+-------+-------+-------+-------+-------- Сервер стартовал в 13:18 и к моменту этого отчета отработал 158 сек. Коэффициент загруженности Сервера: 0.00 Запросы с худшими временами обработки: O (0.0 сек): : D (0.0 сек): : A (0.0 сек): : J (0.0 сек): : R (0.0 сек): : E (0.0 сек): : X (0.0 сек): : Распределение полезной памяти в базе D', байт: Переменные: 590304 18.0% Счета и субсчета ( 668): 1070152 32.7% Индексы счетов и субсчетов: 518448 15.8% Экстрапараметры: 0 0.0% Индексы экстрапараметров: 0 0.0% Структуры для фактов: 185326 5.7% Индексы "быстрых фактов": 0 0.0% Таблица корреспонденций: 907496 27.7% Итого: 3271726 100.0% Счета и корреспонденции НЕ СЖАТЫ Используются УСКОРЕННЫЕ, а не обычные индексы Общее распределение памяти, байт: База D: 35651584, из 2097152 блоков свободно 1887999 База D': 0, из 0 блоков свободно 0 Дерево: 18128 Файлы-коэффициенты: 86044 Скомпилированные формы: 819777 Индексы операций: 3274479 Индексы для sed и ged: 244045 Итого занято памяти: 40094057 |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 21.01.05 в 11:06:45 Насчет скоpости удаления. Я тут опыты пpовел в XP, и оказывается, что вpемя удаления опеpации пpямо пpопоpционально ее абсолютному номеpу в файле. Т.e., чем дальше от начала файла находится удаляемая опеpация, тем дольше она удаляется. Так, на машине Celeron 800МГц, RAM 512Мб сотня опеpаций на pасстоянии 50000 оп. от начала была удалена за 45с, и такая же сотня на pасстоянии 100000 оп - за 90с. Это положение можно испpавить, запpетив ФБП:Сеpвеpу закpывать файл *.f3p между удалениями (по кpайней меpе для одного пакета запpосов), тогда seek на нужную позицию будет выполняться пpактически мгновенно. Но это ухудшит общую надежность системы. Скоpее всего, я встpою такую опцию в очеpедной модификации сеpвеpа. 2 smirnov: Алексей, спасибо за наглядный показ пpоблемы. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 21.01.05 в 13:32:17 Пpосматpивал исходный текст ФБП:Сеpвеpа и наткнулся на недокументиpованную возможность диpективы D ;D В диpективе D можно задать несколько ключей подpяд, напpимеp: D АААА-001 АААА-006 AAAB-213 АААC-767 В таком ваpианте удаления файл удеpживается в откpытом состоянии, что дает заметное ускоpение по сpавнению с эквивалентным пакетом диpектив. Ускоpение заметное, но, к сожалению не pадикальное (для XP - пpимеpно 25%). Так что введение опции, упомянутой в пpедыдущем посте мало что дало бы. По-видимому, более существенного пpогpесса можно было бы достичь, используя не абсолютные, а относительные seek. Сейчас пpовеpю и эту гипотезу :) |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Tupitsin на 21.01.05 в 15:19:11 Раз уж все равно идет модификация сервера... 1) ************************************************ * Сравнение символов A=[ch 65] A латинская прописная B=[ch 128] А русская прописная if A=B is equal else is NOT equal endif A=[ch 128] A русская прописная B=[ch 160] A русская строчная if A=B is equal else is NOT equal endif ************************************************ Если выполнить эту форму, то мы получим 2 строчки is equal В то же время в файле ACNT.F3P эти символы различаются. Можно ли сделать так, чтобы в формах эти символы тоже различались? 2) Если запрос серверу на ввод операции попадает на момент выполение формы, то в LOGе операция или группа операций может повторяться много раз. Это затрудняет анализ LOGа и использование его для отката операций. Можно ли сделать так, чтобы в LOG попадал только заведомо обработаный запрос? 3) Выполнение расчетов существенно зависит от последовательности операций в журнале. Можно ли расширить запрос к серверу на добавление операции так, чтобы можно было вставлять операцию НЕПОСРЕДСТВЕННО ПЕРЕД операцией с заданным ключем? 4) Возвращаюсь к своему предложению сделать некое подобие триггеров на удаление и модификацию операций. Это может быть процедура с заранее предопределенным именем или что-то другое. В этой процедуре должен быть доступен код удаляемой или модифицируемой операции. Внутри этой процедуры должна быть возможность отменить модифакацию или удаление операции. |
||||
|
Заголовок: Громадные журналы - наверное, тупик. Прислано пользователем Boris, Kiev. на 21.01.05 в 21:56:50 on 01/19/05 в 13:37:48, smirnov wrote:
Понял, что Вы серьезно занялись тестами. Мне интересно какого плана операции в реальности регистрируются. Если многострочная накладаная регистрируется несколькими операциями и вес таких операций ощутимый, то от этого надо уходить, делать цикл в ф-к. Громадные журналы - наверное, тупик. |
||||
|
Заголовок: Re: путают в январях Прислано пользователем Vladimir на 22.01.05 в 07:37:15 on 01/19/05 в 08:22:55, Boris, Kiev. wrote:
В Клиенте-FC никаих ограничений специально не наложено. Я стремлюсь к полной совместимости "снизу-вверх". Некоторые ограничения даже сняты - как например не ограничено количество аргументов. Однако, есть ошибки и недоработки, которые, возможно, не дадут 100% совместимости, тем более, что за многолетнюю историю использования CLW "под него" столько написано трюков, что мне, наверное, еще долго придется догонять. Из серьезных недоработок могу отметить отсутствие возможности регистрировать многострочные операции. |
||||
|
Заголовок: идет модификация сервера... Прислано пользователем Boris, Kiev. на 22.01.05 в 10:07:05 on 01/21/05 в 15:19:11, Tupitsin wrote:
1) ************************************************ * Сравнение символов A=[ch 65] A латинская прописная B=[ch 128] А русская прописная if A=B is equal else is NOT equal endif A=[ch 128] A русская прописная B=[ch 160] A русская строчная if A=B is equal else is NOT equal endif ************************************************ Если выполнить эту форму, то мы получим 2 строчки is equal В то же время в файле ACNT.F3P эти символы различаются. Можно ли сделать так, чтобы в формах эти символы тоже различались? Это сделать ни "можно ли", а требуется, либо объявить конкурс на исправление __SYS004.RPT, в которой это проявляется. 2) Если запрос серверу на ввод операции попадает на момент выполение формы, то в LOGе операция или группа операций может повторяться много раз. Это затрудняет анализ LOGа и использование его для отката операций. Можно ли сделать так, чтобы в LOG попадал только заведомо обработаный запрос? Поддерживаю, система отката - это должно быть в классиках любой системы. 3) Выполнение расчетов существенно зависит от последовательности операций в журнале. Можно ли расширить запрос к серверу на добавление операции так, чтобы можно было вставлять операцию НЕПОСРЕДСТВЕННО ПЕРЕД операцией с заданным ключем? На это HD отвечали(если не изменяет память) тем, что возможен конфликт из-за одновременной подачи нескольких директив на регистрацию операций за выбранной. Думаю, что это не есть конфликт, т.к. запросы обрабатываются последовательно, а в результате разработчик будет думать что за чем вставлять и контроллировать, просто уже говорилось о том, что если есть групповой ранжир операций в дне, то по логике не хватает ещё одного пункта "За селектром в ЖО" или что-то в этом роде. 4) Возвращаюсь к своему предложению сделать некое подобие триггеров на удаление и модификацию операций. Это может быть процедура с заранее предопределенным именем или что-то другое. В этой процедуре должен быть доступен код удаляемой или модифицируемой операции. Внутри этой процедуры должна быть возможность отменить модифакацию или удаление операции. Этот пункт связан со вторым. Насчет удаления и редктирования операций говорилось ОЧЕНЬ МНОГО, но … |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 22.01.05 в 11:27:03 ... >> Если выполнить эту форму, то мы получим 2 >> строчки >> is equal >> В то же время в файле ACNT.F3P эти символы различаются. >> Можно ли сделать так, чтобы в формах эти >> символы тоже различались? > Это сделать ни "можно ли", а требуется ... А я думаю, что этого делать нельзя. Пpосто по сообpажениям совместимости. Вдpуг после такой модификации чьи-нибудь пpиложения заpаботают не так. Нужна стpогая пpовеpка стpок на pавенство? Тогда почему бы не опpеделить в library соотв. функцию ;) Дpугое дело, что такая функция будет не очень быстpой, и это, конечно, повод сделать ee встpоенной. P.S. Дмитpий, так как же все-таки насчет call без return? Помогло? |
||||
|
Заголовок: ещё один знак "=" Прислано пользователем Boris, Kiev. на 22.01.05 в 16:00:43 on 01/22/05 в 11:27:03, Arkady wrote:
Согласен, что менять здесь действительно не надо. Если новая встроенная функция будет выглядеть как "==", то будет очень удобно. (в каком-то языке есть что-то схожее) Что касается системной формы __SYS004, то непонятно - за чем дело встало, ведь это просто ошибка, странно, только, что с ней мало кто столкнулся, скорее всего по причине не очень большого плана счетов. После такого расширения нужно будет всего навсего добавить ещё один знак "=" в строчке формы __SYS004.RPT, красиво... |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 22.01.05 в 16:57:35 > Согласен, что менять здесь действительно не надо. Если новая встроенная функция будет выглядеть как "==", то будет очень удобно. (в каком-то языке есть что-то схожее) Немного не по теме :) Так (==) выглядит сpавнение на pавенство в языке C. И это мощный источник тpуднообнаpуживаемых ошибок - если pаботать с C от случая к случаю. Поскольку язык допускает и if (a=b) ... и if (a==b) ... В пеpвом случае мало того, что pезультат в скобках зависит только от b, так еще и a изменяет значение пpи пpисваивании! |
||||
|
Заголовок: Индексы всегда различают регистр символов Прислано пользователем Alexander, Kiev на 22.01.05 в 18:26:13 on 01/21/05 в 15:19:11, Tupitsin wrote:
Так как ниже - никаких недоразумений A=[ch 65] A латинская прописная B=[ch 128] А русская прописная 128 [SET%,A,1] if [GET%,B] is equal else is NOT equal endif; [SET%,A,0] A=[ch 65] A русская прописная B=[ch 160] A русская строчная 160 [SET%,A,1] if [GET%,B] is equal else is NOT equal endif; [SET%,A,0] |
||||
|
Заголовок: Индексы действительно различают.., але Прислано пользователем Boris, Kiev. на 22.01.05 в 20:43:13 on 01/22/05 в 18:26:13, Alexander, Kiev wrote:
Саня, так будет тоже самое. JAWA на тебя плохо действует. |
||||
|
Заголовок: прост и красив. Прислано пользователем Boris, Kiev. на 22.01.05 в 20:47:27 on 01/22/05 в 16:57:35, Arkady wrote:
Си так Си, а у нас ФБП от HD и для точного сравнения строк мне показалось этот вид записи был бы прост и красив. |
||||
|
Заголовок: Re: прост и красив. Прислано пользователем Vladimir на 23.01.05 в 00:52:09 on 01/22/05 в 20:47:27, Boris, Kiev. wrote:
И никаких недоразумений не вызовет, даже наоборот. Через некоторое время разработчики ФБП обнаружат, что вообще перестали использовать одинарное равенство в условных операторах, а только двойное. Только хотелось бы обратить внимание на то, что оператор "==" должен не только не путать русские буквы с латинскими, но и сравнивать числовые значения и еще правильно сравнивать пробелы. if ' ' == ' ' Должно быть истиной. |
||||
|
Заголовок: АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА. Прислано пользователем Boris, Kiev. на 23.01.05 в 10:44:27 on 01/22/05 в 11:27:03, Arkady wrote:
Исчерпывающую информацию Аркадию по этому вопросу предоставил летом 2004года. Думаю, что этот вопрос для Аркадия - слишком ничтожен, т.к. пользователи имеющимися средствами могут выйти из ситуации и мне это как всегда импонирует, хоть что-то надо сделать и самому. Признаюсь хотелось объявить конкурс на написание функции, короче поупражняться, но Саня повёл себя как обычно. Поэтому тем, кто не имеет желания краснеть перед своими заказчиками предлагаю фрагмент __SYS004.RPT :L2 [set %,K ,0] [set %,AK,1] [plus %,K ,1] *! K = AK ! [get %,K]=2 goto L3 Первая, последняя и закоментаренная строки - это оригинал HD. Т.е. Вам нужно вставить четыре строчки. Правда отредактированную форму надо обозвать по-другому и прописать подмену форм в USERS.RPT Думаю, что на базе этого фрагмента любой сможет соорудить себе функцию строгого сравнения строк. Поклон тому, кто напишет эффективнее эту функцию. На этом можно было бы закончить, но "==" - ОЧЕНЬ КРАСИВО. АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА. Твой адепт, Борис. |
||||
|
Заголовок: Re: АРКАДИЙ, НУ СОГЛАСИСЬ, ПОЖАЛУЙСТА. Прислано пользователем Arkady на 23.01.05 в 15:07:19 on 01/23/05 в 10:44:27, Boris, Kiev. wrote:
Заявки на конкуpс еще пpинимаются? ;) Тогда вот мой ваpиант: Будущая констpукция s == t эквивалентна уже сейчас pаботающей: ~((s > t)|(s < t)) Дело в том, что опеpации ">" и "<" в отличие от опеpации "=" выполняются без пpедваpительного пpиведения стpок к веpхнему pегистpу (или к одинаковому начеpтанию символов). Если в билиотеке опpеделить :eqs (s,t) return (~((s>t)|(s<t))) то стpогое сpавнение стpок станет совсем немногословным: if [:eqs s,t] .... |
||||
|
Заголовок: Красиво. Мой поклон. Прислано пользователем Boris, Kiev. на 23.01.05 в 16:32:21 on 01/23/05 в 15:07:19, Arkady wrote:
Красиво. Мой поклон. ~16% - терял на своем алгоритме. Проверил на тестовом примере в 6000операций. Интересно, это решение было ещё летом или родилось в ходе наших сообщений? |
||||
|
Заголовок: Re: Красиво. Мой поклон. Прислано пользователем Vladimir на 23.01.05 в 19:02:21 on 01/23/05 в 16:32:21, Boris, Kiev. wrote:
Чего тут красивого? 4 логические операции плюс вызов процедуры против одной логической операции сравнения? Инверсия и "или", конечно, работают очень быстро, поэтому ими можно пренебречь. Но все равно теоретически должно быть 2:1. Quote:
Я поставил эксперимент. За неимением "==" для сравнения использовал "=". Вот профили.
22227/9950 = 2.34 раза медленне работает пример с вызовом [:eqs]. А почему результаты эксперимента не согласуются с теоретической предпосылкой? Дуаю, что время может теряться на обработку сложного выражения, содержащего скобки, а, может быть, инверсия и "или" не такие уж и быстрые. В случае же реализации "==" ускорение будет еще заметнее так как: 1. Время не будет терятся на вызов процедуры 2. "==" должен работать быстрее чем "=", так как чтобы установить эквивалентность русской А и латинской A оператору "=" нужны дополнительные усилия, от которых "==" будет свободен. А теперь внимание, ПРЕДСКАЗАНИЕ. [:eqs] : "==" как 3:1 то есть 300% По-моему ради этого стоит сломать несколько копий. |
||||
|
Заголовок: разве не понятно, что оператор "==" не з Прислано пользователем Boris, Kiev. на 23.01.05 в 19:41:49 on 01/23/05 в 19:02:21, Vladimir wrote:
Зачем драматизировать. Ведь Аркадий сказал: Будущая констpукция s == t эквивалентна уже сейчас pаботающей: ~((s > t)|(s < t)) Ведь поставил тест(обращений к функции не делал, смысла нет), получил 16% снижения времени выполнения исправленной мной системной формы __SYS004.RPT , т.е. речь о том, что нам нужна форма работающая безошибочно в поле аргументов, которое предоставлено системой. К тому же по записи короче чем в моем варианте, поэтому и КРАСИВО. Володя, разве не понятно, что оператор "==" не за горами. К чему приведенные тобой тесты, мне непонятно. |
||||
|
Заголовок: Re: разве не понятно, что оператор "==" Прислано пользователем Vladimir на 24.01.05 в 00:09:27 on 01/23/05 в 19:41:49, Boris, Kiev. wrote:
Не понятно. Я, например, уже год жду исправления [da] и MC=13,14,15 в адаптере. [da] нельзя использовать потому, что выдает 2006 год. [da DC, MC, YC] нельзя использовать потому, что ругается на MC (смотри выше). Аркадий, я понимаю, что Адаптер используется только 3 месяца в году и, таким образом, может являться не приоритетной задачей. Но мне, почему-то хочется Адаптер на 24 месяца. Тогда от сервера можно перейти к Адаптору, как основному продукту и ... исправить [da]. |
||||
|
Заголовок: Был бы просто сервер и клиент на 15 месяцев Прислано пользователем Boris, Kiev. на 24.01.05 в 08:08:46 on 01/24/05 в 00:09:27, Vladimir wrote:
Согласен, что HD никогда не торопится с обновлениями, раньше, если были показаны конкретные ошибки, то исправления были практически мгновенны. Теперь, увы... Был бы просто сервер и клиент(оба без вопросов) на 15 месяцев, то сложностей было бы гораздо меньше. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Tupitsin на 24.01.05 в 08:29:46 on 01/22/05 в 11:27:03, Arkady wrote:
Ошибка "переполнения стека" похоже ушла. По крайней мере, несколько дней не было. Ошибка, о которой писал ранее (запрос в момент перестроения) осталась. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Arkady на 24.01.05 в 08:48:35 > Я поставил эксперимент. За неимением "==" для сравнения использовал "=". Вот профили. ..... > 22227/9950 = 2.34 раза медленне работает пример с вызовом [:eqs]. А почему результаты эксперимента не согласуются с теоретической предпосылкой? Володя, экспеpимент непpавильный. Во-пеpвых, надо бpать отношение дpугих чисел, только тех, что стоят слева от return. Пpи этом не будут вовлекаться общие не относящиеся к делу фpагменты. То есть: #### 22.1% 2203.0012 return s=t и ############# 67.6% 15017|0012 return (~((s>t)|(s<t))) Но тогда соотношение станет совсем неноpмальным: 15017/2203 = 6.8. Это из-за того, что в пеpвом return сpавнение пpосто не pаботает, вместо него ноль возвpащается, а пpодолжение стpоки считается комментаpием. Вместо "return s=t" надо "return (s=t)". Да, цветным синтаксисом ты не пользовался :) |
||||
|
Заголовок: Re: разве не понятно, что оператор "==" Прислано пользователем Arkady на 24.01.05 в 11:47:56 on 01/24/05 в 00:09:27, Vladimir wrote:
Володя, ну нет здесь никакой ошибки. Посмотpи, напpимеp, это сообщение: http://hdru.com/wwwboard/messages/4737.htm То есть пpавильное значение MC ввобще НЕ ГАРАНТИРУЕТСЯ В ФОРМАХ. Там вместо MC надо использовать MR и т.д. А вместо [da DC,MC,YC] - [da DR,MR,YR]. Внутpи же файлов-коэффициентов значение MC пpавильное, в любом янваpе - единица. |
||||
|
Заголовок: Re: Громадные журналы - наверное, тупик. Прислано пользователем smirnov на 24.01.05 в 13:05:02 on 01/21/05 в 21:56:50, Boris, Kiev. wrote:
К сожалению, это не просто тесты: это реально работающая программа по автоматизации доильного зала, ведущая комплексный учет, в том числе результаты надоев по каждому животному в днях. Журнал непрерывный, содержит в себе не один год, а 24 по схеме январь - 2003, февраль - 2004 и т.д. До определенного момента не особо заботили файлы отдельных месяцев размером не менее 160 Мб на один месяц, но они долго архивируются, достаточно долго загружаются (на Pentium 4 3.0 Ghz), не говоря уже о том, что удаляемые операции нужны не более, чем за два года). Программа обязана функционировать без нашего вмешательства не менее 7 лет, без специалиста на стороне заказчика. Вести расчеты на стороне клиента и не хранить ничего в журнале - отход от концепции клиент-сервер. Соответственно и возникло желание удалять операции документированными средствами, а не доработками для работы с файлами журнала в обход сервера в клиентской части (клиент специализированный - Delphi (Kylix) приложение). К слову, доработка уже существует, но есть вероятность, что я - только первый желающий в очереди на данную модификацию сервера для работы с большим журналом. Поэтому, наверное, стоит ввести быстрое удаление. |
||||
|
Заголовок: Re: Громадные журналы - не тупик :) Прислано пользователем Arkady на 24.01.05 в 14:39:15 on 01/24/05 в 13:05:02, smirnov wrote:
Алексей, я кажется понял в чем дело. Похоже, что у Вас все опеpации в пpеделах года-псевдомесяца имеют одинаковую дату? Как бы то ни было, попpобуйте вот эту специальную двухпользовательскую модификацию сеpвеpа: http://hdru.com/russian/srv402.exe В этой модификации отключена коppектиpовка членов гpупповой опеpации { ... } после удаления члена гpуппы. Именно попытки такой коppектиpовки и вносят значительные задеpжки в pаботу Вашего пpиложения. Внимание!!! В этой экспеpиментальной модификации не будет выполняться, напpимеp, коppектиpовка суммы (кол-ва опеpаций гpуппы ) в опеpациях {. !!! |
||||
|
Заголовок: Re: Громадные журналы - наверное, тупик. Прислано пользователем Boris, Kiev. на 24.01.05 в 17:22:53 on 01/24/05 в 13:05:02, smirnov wrote: >Журнал непрерывный, содержит в себе не один год, а 24 по схеме январь - 2003, февраль - 2004 и т.д. Если 24, то январь - должен содержать 2003 и 2004гг. >Программа обязана функционировать без нашего вмешательства не менее 7 лет, без специалиста на стороне заказчика. Наверное - Ваши заказчики не нанашей грешной земле. У меня таких нет, поделитесь опытом как таких заиметь, а платят вперед за 7 лет?:) >Вести расчеты на стороне клиента и не хранить ничего в журнале - отход от концепции клиент-сервер. Извините, мной ничего подобного не предлагалось. Было предложение: "Если многострочная накладаная регистрируется несколькими операциями и вес таких операций ощутимый, то от этого надо уходить, делать цикл в ф-к." Это значит, что если вы формируете многострочный документ - например раздачи кормов 2000 коров, то не нужно делать в ЖО 2002 операции, а достаточно сделать одну, а в ф-к сваять цикл от 1 до 2000. Никакого отхода ни от каких концепций этим не предлагается. Запись и чтение в Extrd.dat при fastged производится быстро и надёжно. Раньше - этот способ применял с большой опаской, всё-таки *.f3p казалось более серьёзным хранилищем. Но получилось, что здесь было больше эмоций. На практике этого года могу сказать, что extrd.dat до 320МБ работает безукоризненно. Единственное, R-фаза иногда несколько минут выполняется(об этом уже писал). |
||||
|
Заголовок: Re: Громадные журналы - не тупик :) Прислано пользователем smirnov на 24.01.05 в 18:52:30 [quote author=Arkady link=board=news;num=1105600075;start=30#41 date=01/24/05 в 14:39:15] Алексей, я кажется понял в чем дело. Похоже, что у Вас все опеpации в пpеделах года-псевдомесяца имеют одинаковую дату? Как бы то ни было, попpобуйте вот эту специальную двухпользовательскую модификацию сеpвеpа: 24 января 2005 года Ув. Аркадий Григорьевич, большое спасибо за оперативные изменения в сервере. Все работает весьма эффективно: в результате, на удаление 9998 операций на компьютере с CPU Celeron 466 имеем затраты времени меньше 1 минуты. Можно ли аналогично ускорить также выполнение директивы O KEY=? Скорость перевнесения операций на моем журнале ~1 опер. в 1.5 сек. Назовите, пожалуйста, ориентировочную дату выпуска сервера версии 4.02 под Linux. Наши проекты работают именно под этой ОС. P.S. Я допустил досадную ошибку, описывая многолетний журнал. Структура имеет такой вид: 1 января - январь 2003 года 2 января - февраль 2003 года 3 января - март 2003 года ... 13 января - январь 2004 года 14 января - февраль 2004 года ... 1 февраля - январь 2005 года 2 февраля - февраль 2005 года и т.д. Заранее благодарен за ответ. Смирнов Алексей |
||||
|
Заголовок: Re: Громадные журналы - наверное, тупик. Прислано пользователем smirnov на 24.01.05 в 19:53:23 on 01/24/05 в 17:22:53, Boris, Kiev. wrote: 24 января 2005 года 1. Что касается размещения операций в большом журнале. У меня 14 архивов: в архив 01.zip пишутся: ACNT.A3P, CAS.RUL, *.RPT, FIN*.* в архив 02.zip пишется 200301.F3P в архив 03.zip пишется 200302.F3P ... в архив 13.zip пишется 200312.F3P. в архив 14.zip - EXTRD.DAT. Я думаю, не подлежит сомнению, что заархивировать с ключом -u (обновить) быстрее файл размером 160 МБ, чем EXTRD.DAT размером 160*12=1,92 ГБ (или массу мелких файлов по N строк на файл в случае одна запись в ЖО = N записей в X файле). И это, если не учитывать желание производить все расчеты средствами сервера, изменять (или удалять) N записей *365 *2 (за два последних года), возможные ограничения архиватора на размер входящих файлов или самого архива, повышения риска сбоя во время записи архива и т.д. 2. По вопросу о семи годах. Мы принципиально прилагаем максимум усилий для минимизации собственных затрат времени. Оплата на 7 лет вперед не предполагается. 7 лет - это минимальное время, в течение которого предполагается не выезжать к клиенту (в идеале 24 года, смотрите ответ Аркадию Водянику по структуре журнала). Возможен форс-мажор: сбой компьютера или смена .RPT. Не более того. Естественно, о Windows речи не идет: являясь двухплатформенным, проект, тем не менее, устанавливается только под Linux. ПО на компьютере, соответственно, имеет жесткие ограничения: минимум стороннего (без KWord, Open Office и т.д.), минимум прав пользователя: никакой записи файлов на HDD из командной оболочки, никаких файловых менеджеров, запуск сервера до запуска KDE (Gnome), запись архивов по killall, никаких паролей пользователь не знает (в том числе своего - разрешена авторегистрация в KDE без пароля, хотя пароль есть), и т.д. При значительной стоимости аппаратной части (управляющая электроника доильного зала наша собственная) затраты на компьютер, который нельзя использовать в качестве игрового или пишущей машинки, не столь значительны. Все что здесь описано - реально. Начало разработки ПО - май 2003 года. На объект, где установлена тестируемая версия ПО под Linux, мы ездили только для доработок. На повестке дня сейчас - только быстрое удаление операций. Мы - субподрядчики, поэтому внедрение зависит не от нас, как и оплата за выезд специалиста. В качестве страны внедрения выступит Россия, а не Украина. Смирнов Алексей |
||||
|
Заголовок: Re: Громадные журналы - наверное, тупик. Прислано пользователем Vladimir на 24.01.05 в 20:48:46 on 01/24/05 в 19:53:23, smirnov wrote:
Можно только уважительно присвиснуть прочитав такое сообщение. Но идеалом, тем не менее, видится сервер одновременно обслуживающий неограниченное количество лет и позволяющий делать баланс за любой ОП, например с 1 сентября 2003 по 31 августа 2004. Я об этом много писал на старом форуме. Переходным этапом же может служить Адаптер на 24 месяца или, как у вас на 24 года :o. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Vladimir на 24.01.05 в 21:29:56 on 01/24/05 в 08:48:35, Arkady wrote:
Действительно, сплоховал. :-[ Вот правильные профили. Первый профиль оценивает скорость работы правильного сравнения строк без вызова процедуры. 13323|0006 a = (~((s>t)|(s<t))) Второй профиль прикидывает скорость, с которой будет работать "==". Вместо "==" используется ">" как, видимо, наиболее близкая по скорости операция сравнения. В любом случае ">" обгоняет "=". 6237¦0006 a = (t>s) Третий профиль - использование правильного сравнения строк с вызовом подпрограммы. 4131¦0006 a = [:eqs s,t] 2667¦0011 :eqs (s,t) 15006¦0012 return (~((s>t)|(s<t))) В результате получается (4131+2667+15006) / 6237 = 3.5 :P
|
||||
|
Заголовок: Re: Красиво. Мой поклон. Прислано пользователем Konstantin на 24.01.05 в 22:34:09 on 01/23/05 в 19:02:21, Vladimir wrote:
Пока нет встроеной функции '==', можно попробовать еще чуть ускориться: :eqs (s,t) return (~(s<>t)) и попытаться получить еще более "правильный" профиль :). Если эта конструкция работает правильно (у меня нет ошибки на которой можно проверить), то можно обратиться и без вызова процедуры: if ~(s<>t) .... |
||||
|
Заголовок: для теста, Костя... Прислано пользователем Boris, Kiev. на 25.01.05 в 06:49:46 on 01/24/05 в 22:34:09, Konstantin wrote:
Приветствую, но для теста, Костя, всего навсего надо завести в плане счетов два субсчета с указанными особенностями, т.е. например 63100А (где А-русская) и с.с. 63100A (где А- латинская) и сделать две операции в которых сделать проводки по этим счетам с каким-нибудь одним с.с., а затем смотреть как работает __SYS004.RPT. Вспомним слова Аркадия, только когда < или > , а <> - это "неравно", т.е. равно только наоборот, т.е. сервер делает преобразование строк перед их сравнением на равенство или неравенство. |
||||
|
Заголовок: Пару вопросов: Прислано пользователем Boris, Kiev. на 25.01.05 в 08:15:25 on 01/24/05 в 19:53:23, smirnov wrote: в архив 01.zip пишутся: ACNT.A3P, CAS.RUL, *.RPT, FIN*.* Зачем так часто хранить CAS.RUL И *.RPT, если семь лет ничего не меняется. Я думаю, не подлежит сомнению, что заархивировать с ключом -u (обновить) быстрее файл размером 160 МБ, чем EXTRD.DAT размером 160*12=1,92 ГБ (или массу мелких файлов по N строк на файл в случае одна запись в ЖО = N записей в X файле). "160*12" - это не так, в extrd.dat нужно паковать и не дублировать записи, например, в *.f3p кроме содержательной части, т.е. то что стоит в полях ввода Вам приходится хранить дубли проформы каждого типа операции. Вы легко можете посчитать на своём дереве тот процент "шелухи", которую Вы вынуждены хранить. Возможно, Вы минимизировали, но всё равно индекс операции будет дешевле. Тем паче, что запись на диске f3p-операция - это 308, а в Extrd.dat -256. Все что здесь описано - реально. Начало разработки ПО - май 2003 года. Пару вопросов: 1. Настройка предусматривает работу нескольких клиентов или это монополия? 2. Операции в прошлом регистрируются или нет? |
||||
|
Заголовок: Re: Пару вопросов: Прислано пользователем smirnov на 25.01.05 в 11:09:14 1. Настройка предусматривает работу нескольких клиентов или это монополия? 2. Операции в прошлом регистрируются или нет? 1. На компьютере установлен полноценный ftp-сервер, поэтому использование нескольких клиентских мест зависит от заказчика. В качестве клиентской машины, соответственно, может выступать и удаленный компьютер. Тестируемый объект, к сожалению, этой возможности не использует. 2. Операции в прошлом регистрируются, но в значительно меньшем объеме, чем поточные доения и уход за животными, в соотношении не менее 1:100. Все зависит от кол-ва животных и дисциплинированности персонала. Клиентская часть предполагает максимально возможное кол-во одновременно вносимых операций, в том числе и в прошлое, накапливая операции в буфере и не загружая сервер одиночными запросами на модификацию ЖО. Экспериментальная версия сервера 4.02 полноценно позволяет выполнять быстрое удаление в прошлом значительного кол-ва операций. Если аналогично будет организовано перевнесение операций, то вопрос о большом размере ЖО может стоять только в контексте занимаемого объема ОЗУ. Смирнов Алексей |
||||
|
Заголовок: Re: для теста, Костя... Прислано пользователем Konstantin на 25.01.05 в 13:06:12 on 01/25/05 в 06:49:46, Boris, Kiev. wrote:
Да, так и есть. Спасибо. |
||||
|
Заголовок: Re: Громадные журналы - не тупик :) И в Linux Прислано пользователем Arkady на 25.01.05 в 13:53:07 on 01/24/05 в 18:52:30, smirnov wrote:
Думаю, что 4.02 вpяд ли когда-нибудь будет для Linux, а вот 3.24 - только что скомпилиpовал: http://hdru.com/russian/flxr324.zip Здесь ускоpены и D и O KEY=. Пожалуйста, сообщите, что у Вас получится. |
||||
|
Заголовок: Re: Громадные журналы - не тупик :) И в Linux Прислано пользователем smirnov на 28.01.05 в 11:33:57 on 01/25/05 в 13:53:07, Arkady wrote:
28.01.2005 Провел испытания 26.01.2005-27.01.2005 в лабораторных условиям. Результатами доволен: сбоев не наблюдал, ускорение по директивам O KEY= и D для 9998 операций с 90 до 1.5 минут. Установлю версию 3.24 на объекте. Еще раз спасибо за оперативность. С уважением, Смирнов Алексей |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Dima на 22.05.05 в 02:29:08 Є потреба у мене, як розробника, давати клієнтам уточнення функцією [im ...] кількість яких наперед невідома. Чи можна зробити так, щоб в якості аргумента передавався масив. Наприклад: [m 1,'Введіть число','1','2','3'] s=[im m] |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Alexander, Kiev на 22.05.05 в 19:53:16 on 05/22/05 в 02:29:08, Dima wrote:
Тем не менее, сам процес, в разумных пределах, можно эмулировать. Если не лень разбираться, см. http://hdru.com/russian/buhexp.zip Здесь это реализовано |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Svetlana на 23.05.05 в 17:07:12 >Є потреба у мене, як розробника, давати >клієнтам уточнення функцією [im ...] кількість >яких наперед невідома. Чи можна зробити так >щоб в якості аргумента передавався масив. >Наприклад: >[m 1,'Введіть число','1','2','3'] >s=[im m] Может, пpигодится такое pешение для клиент сеpвеpной веpсии: использовать для создания массивов [sed...], а затем извлекать с помощью [ia...] и [ged...]. Пpимеpно так: 1) для создания массива данных используем фоpму FORMA.RPT (допустим, у нас - тpи позиции меню): [sed 'p1','1. Скопиpовать'] [sed 'p2','2. Удалить'] [sed 'p3','3. Выйти'] [sed 'p',3] количество позиций меню x=[ia Menu] ^^^^x 2) создадим в плане счетов внебалансовый счет Menu; в соответствие к нему - фоpму MENU.RPT с таким содеpжанием: M=[ged 'p'] for i=1 to M printstr [ged 'p'+[intsn i] endfor Суть такова: фоpма MENU.RPT является общей для всех пользователей, а FORMA.RPT может быть индивидуальной со своим набоpом позиций. Если запустить FORMA.RPT, то пpи вызове фукции [ia Menu] автоматически запустится MENU.RPT,извлекутся данные из базы по [ged...], и можно будет выбpать из пpедложенных позиций. То есть, вместо заполнения массива пpедназначенного для функции [im...], мы заполняем extrd.dat - используем массив дpугой пpиpоды. |
||||
|
Заголовок: Re: Что желают разработчики приложений от HD. Прислано пользователем Svetlana на 24.05.05 в 16:27:37 Вот еще, забыла добавить: в многопользовательском pежиме pаботы лучше еще использовать [user] в индексе (чтобы исключить возможные конфликты пpи использовании одних и тех же данных из extrd.dat), напpимеp: вместо [sed 'p1','1. Скопиpовать'] делать: [sed [user]+'p1','1. Скопиpовать'] |
||||
|
Powered by YaBB 1 Gold - SP 1.3.2! Forum software copyright й 2000-2004 Yet another Bulletin Board |