Финансы без пpоблем: Пеpеговоpный Пункт II (http://hdru.com/cgi-bin/pp2/YaBB.cgi)
>> Пpедложения по усовеpшенствованию, сообщения об ошибках >> Нестандартное использование Сервера ФБП
(Message started by: MELVIS на 16.11.12 в 14:46:40)

Заголовок: Нестандартное использование Сервера ФБП
Прислано пользователем MELVIS на 16.11.12 в 14:46:40
Сразу прошу Автора Сервера ФБП и Сообщество ФБП простить меня за не совсем стандартный подход к использованию Сервера ФБП.

Основные задачи:
1.      Расширение возможностей работы с журналом операций (паралельная работа с БД  с разными форматами, содание (интегрирование) обьединённых БД в реальном времени).
2.      Оптимизация, логики перерасчёта Сервера при внесении изменений в прошлом (перерасчёт не прерывается при cоздании новой операции в прошлом, а проводится до полного завершения, новые и изменённые операции за время перерасчёта накапливаются в буферном журнале операций и «подкладываются» Серверу в виде готового *.f3p, а уже потом производится новый перерасчёт с учётом этих операций).
3.      Использование многоядерности процессора, повышение быстродействия Сервера за счёт сосредотачивания работы Сервера только на вычислительных функциях - работу с файлами операций выполняет «буферное» приложение.
4.      Возможность расширенного администрирования прав ползователей.
5.      Обход ограничения для длинны строки запроса к Серверу в 255 символов (редко, но иногда бывает).
6.      Создание системы автоматического востановления БД при аварийном завершении работы Сервера.
7.      и многое другое ....

Способ решения:
1.      Создание «буферного» приложения, которое выполняет роль «администратора-синхронизатора-интегратора». «Буферное» приложение полностью берёт на себя работу с файлами *.f3p, и  готовые файлы *.f3p подкладывает Серверу после завершения перерасчёта. После «подкладки» нового (изменённого) *.f3p Сервер делает перерасчёт по команде P mc=*.

Проблема:
При такой «подкладке» *.f3p Сервер всё делает отлично, за исключением одного –  не работает директива jf по операциях созданных не Сервером.
Учитывая то, что мы полностью ушли от TXA, это для нас очень большая проблема.

Опробовать «подкладку» можно на любой базе по такой методике:
1.      запускаем два Сервера на двух поностью одинаковых базах 1 и 2 (копии одной базы);
2.      создаём новую операцию в базе 2;
3.      при работающих Серверах 1 и 2 копируем *.f3p с  новой операцией из базы 2 в базу 1
4.      даём команду на перерасчёт в базе 1;
5.      смотрим результат в базе 1 (Сервер даёт проводки по новой «чужой» операции, но jf по новой операции которая создана без участия Сервера 1 не работает– нет операции)


!!! Эта методика только для выявления "нерабочей" jf при подкладывании чужих операций.
!!! «Буферное» приложение – это не Сервер ФБП


Ми поняли, что Сервер не обновляет индексы штампов операций при пререрасчёте.
Это так?
Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 16.11.12 в 19:40:17

on 11/16/12 в 14:46:40, MELVIS wrote:
Сразу прошу Автора Сервера ФБП и Сообщество ФБП простить меня за не совсем стандартный подход к использованию Сервера ФБП.

Основные задачи:
1.      Расширение возможностей работы с журналом операций (паралельная работа с БД  с разными форматами, содание (интегрирование) обьединённых БД в реальном времени).

Интегрирование уже не может быть в реальном времени, т.к. реально дельту времени к 0  в числовых методах не привести.


Quote:
2.      Оптимизация, логики перерасчёта Сервера при внесении изменений в прошлом (перерасчёт не прерывается при зоздании новой операции в прошлом, а проводится до полного завершения, новые и изменённые операции за время перерасчёта накапливаются в буферном журнале операций и «подкладываются» Серверу в виде готового *.f3p, а уже потом производится новый перерасчёт).


Исключите возможность работы с ЖО для клиентов базового сервера и эта проблема станет не актуальной.



Quote:
3.      Использование многоядерности процессора, повышение быстродействия Сервера за счёт сосредотачивания работы Сервера только на вычислительных функциях - работу с файлами операций выполняет «буферное» приложение.


По всей видимости, «буферное» приложение уже реализовано Вами. А в самом пересчете распараллелить что-либо в учете в наших регистрах– проблематично, т.к. они, как правило переплетаются.


Quote:
4.      Возможность расширенного администрирования прав ползователей.


Чего именно, Вам не хватает сегодня.


Quote:
5.      Обход ограничения для длинны строки запроса к Серверу в 255 символов (редко, но иногда бывает).


«Краткость – сестра …»
Ради чего и до какого объема, на эту тему были обсуждения, пока не видно большого смысла.



Quote:
6.      Создание системы автоматического востановления БД при аварийном завершении работы Сервера.


Эти проблемы чаще на администраторах всегда и везде.


Quote:
7.      и многое другое ....


Вот так всегда….


Quote:
Способ решения:
1.      Создание «буферного» приложения, которое выполняет роль «администратора-синхронизатора-интегратора». «Буферное» приложение полностью берёт на себя работу с файлами *.f3p, и  готовые файлы *.f3p подкладывает Серверу после завершения перерасчёта. После «подкладки» нового (изменённого) *.f3p Сервер делает перерасчёт по команде P mc=*.

Проблема:
При такой «подкладке» *.f3p Сервер всё делает отлично, за исключением одного –  не работает директива jf по операциях созданных не Сервером.
Учитывая то, что мы полностью ушли от TXA, это для нас очень большая проблема.


Не очень понятна связь. Вы в TXA выводили фразу операции?
Для чего Вам [jf    ???, ведь Вы  уже операции сформировали, а потом  хотите получить от сервера подтверждение, что они такие же, как Вы ему «подложили»? Если Вы хотите редактировать на базовом, то см.совет  в п.2.
Редакция – это реальная проблема в предложенной технологии, а [jf – нет.
Quote:
Опробовать «подкладку» можно на любой базе по такой методике:
1.      запускаем два Сервера на двух поностью одинаковых базах 1 и 2 (копии одной базы);
2.      создаём новую операцию в базе 2;
3.      при работающих Серверах 1 и 2 копируем *.f3p с  новой операцией из базы 2 в базу 1
4.      даём команду на перерасчёт в базе 1;
5.      смотрим результат в базе 1 (Сервер даёт проводки по новой «чужой» операции, но jf по новой операции которая создана без участия Сервера 1 не работает– нет операции)

Ми поняли, что Сервер не обновляет индексы штампов операций при пререрасчёте.
Это так?
Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?


Можно, при том, не меняя ничего на сегодня в сервере. Просто могу обновить свой bk.lib  для Вас и будет Вам счастье.:)

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



Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем MELVIS на 16.11.12 в 21:32:33
Спасибо за детальный анализ нашего сообщения и критику, но ответа на поставленный вопрос мы не получили:
«Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?»
Всё остальное – это наши проблемы. После завершения работы над проектом, если у Вас будет желание, мы продемонстрируем его достоинства.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем mine-R на 17.11.12 в 04:07:06

on 11/16/12 в 21:32:33, MELVIS wrote:
...Всё остальное – это наши проблемы...
При подобных манипуляциях с *.f3p, имхо, кратно возрастает вероятность появления не уникальных ключей в штампах операций. А это уже серьезный фактор, дестабилизирующий систему.
По сути же вопроса - можно опробовать следующий вариант: В каждом месяце в начале дня иметь операцию, которая ничего не делает

¦¦  x  x  (0)

со штампом AAAA-001 для января, ВAAA-001 для февраля и.т.д..... и вместо запроса на пересчет, править операцию в нужном месяце, например

o KEY=AAAA-001... и.т.д....

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Iamik на 17.11.12 в 09:50:17

Quote:
со штампом AAAA-001 для января, ВAAA-001 для февраля

мда, в вашей логике эта дестабилизирующая ситуация как раз и проявилась .... Не может существовать два штампа AAAA-001 и BAAA-001 потому что уникальность определяется без учёта первого символа. В правильных руках всё будет работать нормально  ;)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем MELVIS на 17.11.12 в 10:57:39
Для mine-R "При подобных манипуляциях с *.f3p, имхо, кратно возрастает вероятность появления не уникальных ключей в штампах операций."

В нашем варианте присваивание и контроль за уникальностью штампов операций - это работа «буферного» приложения. Проблем нет - опробовано на практике.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем mine-R на 17.11.12 в 13:44:40

on 11/17/12 в 09:50:17, Iamik wrote:
...мда...
В чем противоречие? Было указано возможное направление и наглядно показаны острые углы, которые необходимо обойти. Так что, штампы сосуществовать вполне себе могут, но до первой перезагрузки сервера.


on 11/17/12 в 10:57:39, MELVIS wrote:
В нашем варианте присваивание и контроль за уникальностью штампов операций - это работа «буферного» приложения. Проблем нет - опробовано на практике.
Заинтриговали  :) Возможно, я не совсем корректно представил себе технологию работы из Вашего перврго поста. N-ное количество серверов выводят в файлы *.in  запросы напрямую в box "результирующего" сервера?

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем MELVIS на 17.11.12 в 15:58:11
Re mine-R
"Заинтриговали  :) Возможно, я не совсем корректно представил себе технологию работы ..."

Да, Вы совсем не поняли нашего подхода. Сервер читает готовые файли *.f3p.
«Буферное» приложение управляет запросами к Серверу и, как администратор запросов, не пропускает Серверу директив по работе с журналом операций, а полностью берёт на себя эту работу. Берёт на себя и «многое другое...». Прошу воспринять эту фразу не из-за того, что нечего сказать, а потому что «многое другое...» не есть предметом обсуждения в данном случае. По завершении проекта, если у Сообщества будет интерес, мы обнародуем его для критики.
Нам нужно только чтобы заработала jf при «подкладывании» Серверу файла *.f3p.


Надеюсь Автор услышит нашу просьбу и выскажет своё мнение по этому вопросу.
Автор – всегда прав, на то он и Автор.
Очень бы хотелось получить его понимание.
 



Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем BBBB на 17.11.12 в 16:55:30
А почему вам не нравится предложение Бориса о решении вопроса с jf? Если он уже увидел как это сделать - почему нет?
И все равно не понятно - почему результирующему серверу ставятся такие жесткие условия - и не перестартовывать, и не пересчитывать, и не принимать *.in из _box_ - но выдать все по jf. Может вам тогда и не ФБП:сервер нужен?

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 17.11.12 в 17:28:55

on 11/16/12 в 21:32:33, MELVIS wrote:
Спасибо за детальный анализ нашего сообщения и критику, но ответа на поставленный вопрос мы не получили:
«Возможно ли решить проблему «невидения» операций Сервером по jf при «подкладывании» файла *.f3p ?»


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

Также вношу коррективы к своему первому посту, что и с редакцией(это второй момент, на котором Вы  пока не акцентировали внимания) подложенных операций, как и с обходом [jf( это первый ваш вопрос) реализуемы без внесения изменений в текущую версию сервера. Решение второго вопроса конечно накрывает и первый, как бы уже и заодно. Решение простое, но специфичное в тонкостях реализации и потребует условий для ваших «буферов» или «буферных приложений» и конечно элементов взаимодействия.

Quote:
Всё остальное – это наши проблемы. После завершения работы над проектом, если у Вас будет желание, мы продемонстрируем его достоинства.

Вижу без демонстрации достоинство Вашей системы в актуальности для учета, не требующего перманентной актуализации отчетных и вспомогательных форм для ввода, ред. или удаления операций. Актуальность вашей системы в гораздо большей реактивности промежуточных серверов(кот. Вы назвали буферными приложения) на действия оператора, т.к. Вы организационно развели по веткам учет на своем предприятии и вероятно правильно  сделали.  Тем самым специализировав комплекс программ для решения поставленных перед Вами задач. Ура, что есть у нас такие. С другой стороны Ваш комплекс, вероятно, далек от универсальности  нашего уважаемого ФБП-сервера. Вносить изменения в сервер, которые посвящены  согласованию с нештатным его использованием, согласитесь, что этому нет ни конца ни краю, при чем в Ваших силах самим додуматься до решения, которое уже существует, ведь это уже 99% решения, т.к. уверенно знаешь, что есть решение, только, оно не записано на последней странице учебника). Думаю, что так веселее.

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

Ударим рифмой прозу дня
Чтоб веселее жить друзья

Финансы революшн на пороге
Кланяемся новой проге
Буфера Виталия сервер вознесут
Сервера в охотку лихо разметут.:)

P.S. Делаю ставки на BBBB и Mine-R, эти ребята скоро дадут Вам решение.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем mine-R на 17.11.12 в 20:23:50

on 11/17/12 в 17:28:55, Boris, Kiev. wrote:
...P.S. Делаю ставки на BBBB и Mine-R, эти ребята скоро дадут Вам решение.
:) Я "свой" вариант решения выше обозначил. Если добавление новых операций в результирующем сервере запрещено, то проблемы уникальности штампов возникнуть не должно. Но синхронизировать то, что уже в озу с тем, что подложили как-то нужно, потому и предложил, чтобы результирующий сервер перед пересчетом, редактировал заготовленную операцию-пустышку.
Мне любопытен также средний объем в Mb подкладываемых f3p. И использование/неиспользование прочих авантюрных схем (напр. загон одной из баз или даже обеих вместе с каталогами обмена в ram-диски и.т.п. )

P.S. Наверняка есть и элегантные решения на основе loaddir (к примеру, чтобы не включать пересчет, если вдруг подложили неизменившийся f3p), но готовых наработок у меня нету  :)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем chipic128 на 18.11.12 в 23:40:56
Вопрос к создателю сервера!
У Вас в компютере сегодня сколько ядер?
Думаю больше чем 1, а сервер ФБП на скольких работает - на 1., почему ми не продвинулись в сторону развития а зависли на стадии 90-х годов. Ми работаем на ФБП уже продолжытельное врема, у нас работает много подразделений на которых тоже ФБП, НО - страшные тормоза при работе например с параметрами 3-и или более месяца назад, и сервер страшно ТУПИТ, когда изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают - "Почему мои дание не актуальны", тогда я в ручном режыме отключаю прием *.in, дожидаюсь конча перерасчета и тогда восстановляю работу. Неправильно все это. Эту проблему можна решить очень просто, и + к всему использовать многопоточность на разных ядрах и разних процесорах. Понимаю что перерасчет по разных ядрах не раскинуть, поскольку нужно соблюсти последовательность, но обработку форм спокойно можно разнести по ядрах. И кстати после долгого диалога со Светланой насчет команды Р - и P + так результата и не вышло - даная комманда не работает на сервере х64, мне сообщили что после выпуска новой версии учтем, версия вышла, команда не работает и из мануала тупо убрали.... это проще всего.
Да Технология сервера СУПЕР но почему так сложно дошлифовать его до совершенства???

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Vladimir на 19.11.12 в 06:07:50
Вопрос задан разработчикам, я не разработчик, но позволю себе прокомментировать некоторые соображения т.к. поднятые вопросы уже не раз обсуждались.


on 11/18/12 в 23:40:56, chipic128 wrote:
изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают....


Полностью согласен с chipic128. Правильно было бы изменить логику работы сервера. Не сбрасывать расчеты на начало сентября (для данного примера) а "добивать" до конца подбирая по пути измененные файлы октября, ноября, тем более, что, как я понял, пользователи "наяривают" в ноябре.


Quote:
обработку форм спокойно можно разнести по ядрах.


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

Переделка сервера под многопоточность задача сложная, сопряжена с переделкой кода и, по сему, чревата непредсказуемыми последствиями в смысле возникновения ошибок. Результат же усилий может оказаться не столь впечатляющим.
К стати, существенного ускорения работы, кажется, можно добиться и "малой кровью"  - без существеннй переделки кода. Надо просто вежливо попросить операционную систему напрячь процессор по-полной. Это называется Intel Turbo Boost Technology.
http://www.intel.com/content/www/us/en/architecture-and-technology/turbo-boost/turbo-boost-technology.html


Quote:
но почему так сложно дошлифовать его до совергенства???


Ответ очевиден. Совершенство не достижимо! :)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 19.11.12 в 11:55:17

on 11/18/12 в 23:40:56, chipic128 wrote:
сервер страшно ТУПИТ,


На эти вопросы, создатель не раз отвечал, почитайте архивы.

Почитайте руководство о режимах OLD DUAL
OLD__ DUAL__

Сегодня не нужно приобретать машину с многими ядрами, если планируете её выделить исключительно под ФБП-севрер.
Сравните работу одной и той же базы на разных машинах по ядрам.
Пользуете raid0 или нет?


Сделайте аудит настройкам. Найдите свои узкие места, ведь есть профиллер в отличие от других инструментов, может кто подскажет(просто для общего развития), какой сегодня ещё аналогичный инструмент может предложить такую возможность.
Шлифуйте настройки. ;)

P.S. И конечно, если удастся воспользоваться советами и продвинуться, не сочтите за труд клипнуть сюда, а то обидно - "ТУПИТ" и всё.
P.S.2. И не очень понятно, чего отклонились от темы буферных приложений. Про "ТУПИТ" лучше писать в отдельную ветку, а лучше поискать эту тему в архивах и продолжить там, конечно если останутся вопросы и предложения.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Denis, Dnepropetrovsk на 19.11.12 в 12:05:36

on 11/18/12 в 23:40:56, chipic128 wrote:
Ми работаем на ФБП уже продолжытельное врема, у нас работает много подразделений на которых тоже ФБП, НО - страшные тормоза при работе например с параметрами 3-и или более месяца назад, и сервер страшно ТУПИТ, когда изменение было сделано напр. в 9-м месяце, понятно что сервер начинает отсчет с 9-го, НО далее в 9-й никто ничего не вносит и не изменяет, все работают в 11, - НО сервер почему-то думает что все сидят в 9-м и не вылазит из него - все считает и считает, а пользователи наяривают - "Почему мои дание не актуальны", тогда я в ручном режыме отключаю прием *.in, дожидаюсь конча перерасчета и тогда восстановляю работу.


Не могу поверить, что для всех ваших пользователей всегда нужны актуальные данные для продолжения работы ;D. К тому же если Ваши пользователи успевают вводить операции раньше чем сервер выполняет перерасчет 2-х месяцев, то получается что у вас такое огромное количество операций что сервер долго выполняет пересчет (у меня например 15000-20000 операций в месяц пересчитывается за 2 сек.). Поэтому вам следует искать варианты для уменьшения этого количества (например упаковывать документ в 1 операцию. По собственному опыту скажу, что без упаковки мне например не хватило-бы штампов для ввода всех  операций в режиме 1 операция=1 строка документа).
А по поводу актуальности данных считаю, что для 99% случаев актуальность данных не имеет никакого практического значения ;D.

PS Попробуйте режим DUAL (в нем отчетные формы выполняются даже при идущем перерасчете). При активном использовании extrd.dat включайте fastged. И будет Вам счастье в плане скорости.  ;D

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем chipic128 на 19.11.12 в 22:48:08
от темы я не отклонился, поскольку даный буфер бы ускорил работу системы в целом.

Quote:
Не могу поверить, что для всех ваших пользователей всегда нужны актуальные данные для продолжения работы Grin

а я немогу поверить что вашым пользователям плевать на то что ктото изменил остатки на складе...
конечно у нас dual и RAID не просто 0 но - RAID 10 на SAS винтах, так что проблем с ресурсами нет.
у нас за год больше 2 500 000 операций, 30 пользователей, причем под каждым из них сидит больше одного реального юзера.

НО - что делать если нам припустим надо обеденить несколько баз в единую, да так чтобы даные были наиболее актуальны. Такая ГИПЕР база будет занимать ох как немало места и перерасчет тоже будет непрост. Интересно как другие работают с таким множеством даных.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 20.11.12 в 09:45:32

on 11/19/12 в 22:48:08, chipic128 wrote:
.. Интересно как другие работают с таким множеством даных.


От темы отклонились, ну да ладно...

В настройках по гипермаркетам все большие(15-25тыс. списаний номенклатуры в день, приходов по-меньше) многострочники упаковываются в одну операцию. За год порядка 250-400 тыс. операций. Операций в вашей трактовке 5 500 000 – 9 500 000. Картина по нескольким гипермаркетам сворачивается по суммам за нужный период для гл.буха. При анализе – переход в нужную базу нужного филиала(гипермаркета).
Extrd.dat каждого филиала – больше 1Гб на диске не было.
Загрузка рабочей годовой базы филиала 30-50 сек.
Пересчет полной аналитики филиала за год 10-13 минут.

«Нельзя объять необъятное»
«Разделяй и властвуй»

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем chipic128 на 20.11.12 в 10:24:31

Quote:
В настройках по гипермаркетам все большие(15-25тыс. списаний номенклатуры в день, приходов по-меньше) многострочники упаковываются в одну операцию.

для необразовных, как в одну операцию можно впихнуть 30 наименований номенклатуры???

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 20.11.12 в 11:07:14

on 11/20/12 в 10:24:31, chipic128 wrote:
для необразовных, как в одну операцию можно впихнуть 30 наименований номенклатуры???

Вы настройщик или администатор?
Здесь в архивах можно найти подробные описания как это сделать, правда никто не мещает сделать по своему.
Коротко, то в ф-к обращаемся к записям в Extrd.dat и крутим циклы без ограничений.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 20.11.12 в 20:48:04

on 11/20/12 в 10:24:31, chipic128 wrote:
для необразовных, как в одну операцию можно впихнуть 30 наименований номенклатуры???

Этой методике, уже лет 15, не меньше будет. И описывалось и примеры есть. Ищите в старых архивах по ключу "упакованный многострочник"
Давно я сюда не заглядывал, а запал ФБП-шников неугасим. :)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 20.11.12 в 22:52:37

on 11/20/12 в 20:48:04, Alexander_Kiev wrote:
Этой методике, уже лет 15, не меньше будет. И описывалось и примеры есть. Ищите в старых архивах по ключу "упакованный многострочник"
Давно я сюда не заглядывал, а запал ФБП-шников неугасим. :)

Саня, не верю своим глазам, как твой java, расскажи, ты ещё в Украине?

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 21.11.12 в 10:47:24

on 11/20/12 в 22:52:37, Boris, Kiev. wrote:
Саня, не верю своим глазам, как твой java, расскажи, ты ещё в Украине?

Дык, последние 20 лет и не пытался покинуть "нэньку". Удрал только с Киева, вот сейчас первая зима будет за городом. Приложением финансов на java, пользуются где то 25 клиентов. Суперов среди их нет, в максимуме до 30 пользователей, но на жизнь хватает.  
Теперешний уровень мобильной связи практически полностью удовлетворяет потребностям в информационных коммуникациях. И никакой необходимости бороться с городской суетой. В последнее время только МТС-ы стали сильно огорчать. Upload, ниже плинтуса, 20-30 Kbit/c, для отправки файлов приходится использовать альтернативный "интертелеком". А прием в среднем 500 Kbit/c, вполне приемлемо.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем alushta на 22.11.12 в 07:28:29
Александр. Можно поподробнее о Приложении финансов на java

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 22.11.12 в 09:05:02

on 11/22/12 в 07:28:29, alushta wrote:
Александр. Можно поподробнее о Приложении финансов на java

Да нет никаких подробностей, просто последовал подходу Аркадия, автора ФБП, и построил систему управленческого учета, отказавшись от использования серийных СУБД. Общий подход сохранился в самых базовых принципах, как например автоактуализация. Сначала было полностью независимое клиентское приложение на java, с сервером ФБП, потом и на сервер посягнул. 10 лет будет в марте следующего года, как это крутится. Процентов 70 ваших проблем решаются с независимым клиентом, а сервер, это уже больше для души.
Независимый клиент, может, к примеру, решить проблему консолидированной отчетности за несколько лет или кучи отдельных филиалов каждый с своей локальной системой клиент-сервер. Распараллеливания функций, с той же сортировкой и т.п.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 22.11.12 в 17:28:44

on 11/22/12 в 09:05:02, Alexander_Kiev wrote:
Да нет никаких подробностей, просто последовал подходу Аркадия, автора ФБП, и построил систему управленческого учета, отказавшись от использования серийных СУБД. Общий подход сохранился в самых базовых принципах, как например автоактуализация. ...

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

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 22.11.12 в 19:25:23

on 11/22/12 в 17:28:44, Boris, Kiev. wrote:
Хорошо, а вопросы конструкторских возможностей ФБП-сервера так до сих пор и отставлены, т.е. все осталось как и было на поcледний разговор с тобой - узкоспециализированное приложение без намеков поддержки и развития без помощи создателя-ибн-Саши.
Мыслей в эту сторону нет, или что-то новое появилось?

У меня и в мыслях никогда не было конкурировать за возможность представлять продукт для разработчиков. Моя ниша - конечный пользователь системы учета. А то можно подумать, придет дядя с улицы и будет вместо тебя поддерживать твой продукт на ФБП. Я не от кого не завишу, ни на кого не опираюсь и ничего не выпрашиваю. Мои возможности ограниченны только средствами разработки десятков тысяч кодеров и они еще далеко не исчерпаны.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Boris, Kiev. на 22.11.12 в 20:27:00

on 11/22/12 в 19:25:23, Alexander_Kiev wrote:
У меня и в мыслях никогда не было конкурировать за возможность представлять продукт для разработчиков. Моя ниша - конечный пользователь системы учета. А то можно подумать, придет дядя с улицы и будет вместо тебя поддерживать твой продукт на ФБП. Я не от кого не завишу, ни на кого не опираюсь и ничего не выпрашиваю. Мои возможности ограниченны только средствами разработки десятков тысяч кодеров и они еще далеко не исчерпаны.

Можно поспорить, т.к. у меня есть преценденты поддержки не родных настроек.
Скорее всего на ФБП будет быстрее реализовать совершенно новый проект, нежели тебе или из твоей практики уже можно заключить, что это не так? В любом случае, рад за тебя. Успехов!
P.S. В каком направлении домик поставил бывший ФБП-шник, если не секрет, конечно. Небось, Конча :)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 22.11.12 в 21:08:57

on 11/22/12 в 20:27:00, Boris, Kiev. wrote:
Скорее всего на ФБП будет быстрее реализовать совершенно новый проект, нежели тебе или из твоей практики уже можно заключить, что это не так?

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

Quote:
В каком направлении домик поставил

Домик на вотчине благоверной за Переяслав Хм. 25 км. Всего от Киева 120 км. Делать мне нефиг, еще за землю платить.


Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем chipic128 на 22.11.12 в 22:07:27

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


если не тяжело - хотя б скрин, чтобы одним глазом взглянуть на такой шедевр  ;)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 23.11.12 в 09:41:13

on 11/22/12 в 22:07:27, chipic128 wrote:
если не тяжело - хотя б скрин, чтобы одним глазом взглянуть на такой шедевр  ;)

Если консолидация данных от годичных серверов - шедевр, смотрите (http://img13.imageshost.ru/img/2012/11/23/image_50af2896429b8.jpg)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем chipic128 на 23.11.12 в 11:16:42
Тогда к Вам вопрос,... в даном клиенте вообще есть понятие ОПЕРАЦИЙ, или все сделано так, чтобы пользователь даже и не знал об их существовании???
т.е. пользователи напрямую вводят операции как в стандартном клиенте, или это все сделано через спец формы с помощю которых и генерируются операции и даные в extra.dat???
и еще вопрос-предложение: никто не пробовал связки ФБП и СУБД MS SQL | MySQL??
ведь соласитесь что ФБП трудно сравнится с языком запросов к таким СУБД (SELECT *.......)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Alexander_Kiev на 23.11.12 в 14:54:36

on 11/23/12 в 11:16:42, chipic128 wrote:
Тогда к Вам вопрос,... в даном клиенте вообще есть понятие ОПЕРАЦИЙ, или все сделано так, чтобы пользователь даже и не знал об их существовании???

Понятие «операции» относится к серверу. Пользователь должен иметь доступ к результатам операций и к их телу для редакции или создания новых. Уровень такой реализации относится к интерфейсу клиента с конечным пользователем. Штатный клиент ФБП использует последовательный доступ к полям операций и имеет отчетную форму журнала операций в виде, который устраивает не всех. Те кого это не устраивает ищут пути улучшения, а сервер при этом, совсем ни при чем.


Quote:
никто не пробовал связки ФБП и СУБД MS SQL | MySQL??
ведь соласитесь что ФБП трудно сравнится с языком запросов к таким СУБД (SELECT *.......)

Этот вопрос, свидетельствует о том, что Вы не осознаете принцип на котором построен ФБП-сервер. Этот сервер почти не использует дисковую память, как это делают практически все СУБД. Формат данных максимально ограничен и специализирован. Это дает возможность, все введенные и расчетные данные держать в оперативной памяти, в виде объектов(записей). За счет этого к ним достигается доступ с непревзойденной быстротой, позволяющей организацию автоактуализации при вмешательстве в прошлое. Такое, при роботе с СУБД, никто не может себе позволить.  Как только Вы задумаете использовать стандартную СУБД, про преимущества ФБП сервера и его самого можно забыть.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем BBBB на 26.11.12 в 07:24:46
В конце концов, вырисовывается - что автор темы готовится скрестить MySQL с ФБП.
Причина - большие объемы данных и связанная с ними обработка.

Тогда вопросы:
1) для оптимизации своих настроек - использовался ли Профилер? Его помощь на
больших настройках - неоценимая! Иногда переписка алгоритма приводит на больших базах
эффект такого ускорения - что и не ожидаешь. А ведь вы не показали здесь ни одной картинки
с результатами Профилера - здесь нашлись бы советы от практиков.

2) изучался ли вопрос работы с ОДА? Вот здесь ее сферы применения:
Обмен данными между офисом и удаленными складами.
Обмен данными между удаленными офисами.
Обмен данными между системами реального времени и официального учета.
Экспорт данных в системы консолидированного учета группы предприятий.
Экспорт данных в системы учета, построенные на других платформах.
Импорт данных из различных систем.
Организация псевдо-сетевой работы на однопользовательских версиях.  

Ну и компьютер-сервер должен быть тогда уж не прсто компьютер, а какой-то серверный вариант.

Все ведь уже сделано и оптимизировано - нужно учиться пользоваться этим.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Svetlana на 26.11.12 в 11:46:19
Такая вот информация к размышлению:

Обратилась к одному нашему старому клиенту по вопросу количества  данных и способов организации работы, вот их характеристики (направление: сеть аптек):
- в месяц 5-6 млн операций!
- сервер ФБП 64-х разрядный на 50 имен версии 4.3 с синхронизацией, 64 Гб ОЗУ, система Windows Server 2003;
из-за больших баз предыдущие два года по полгода закрывали базу, до этого - по кварталам, в этом году - только 1-й квартал.

На клиентских местаях используется только стандартный clw, но есть клиентские места где написаны самостоятельно программы для извлечения данных из MySQL, все это собирается в файлы *.txt и затем отправляeтся ФБП:серверу в виде *.in.

P.S. конечно, предшествовала и работа по оптимизации настроек, и увеличение ОЗУ.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Iamik на 26.11.12 в 11:55:49

on 11/26/12 в 07:24:46, BBBB wrote:
2) изучался ли вопрос работы с ОДА

Что такое ОДА, и гре можна посмотреть описание ? Сделал поиск по всему форуму и ничего не нашел.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Svetlana на 26.11.12 в 12:06:56
Это разработка Васеленко Сергея (есть в списке дилеров и разработчиков):
http://www.cardinal-soft.com

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Denis, Dnepropetrovsk на 26.11.12 в 13:15:06

on 11/26/12 в 11:46:19, Svetlana wrote:
Такая вот информация к размышлению:

Обратилась к одному нашему старому клиенту по вопросу количества  данных и способов организации работы, вот их характеристики (направление: сеть аптек):
- в месяц 5-6 млн операций!
- сервер ФБП 64-х разрядный на 50 имен версии 4.3 с синхронизацией, 64 Гб ОЗУ, система Windows Server 2003;
из-за больших баз предыдущие два года по полгода закрывали базу, до этого - по кварталам, в этом году - только 1-й квартал.



Похоже я что-то пропустил ??? ???
В руководстве написано:

Quote:
b) в сетевых веpсиях:
явно заданных огpаничений нет, следует знать, что записи в файлах *.f3p содеpжат штампы с уникальными кодами опеpаций. Эти коды устpоены так:

MLLL-000
где
M - это месяц: A-янваpь, B-февpаль и т.д.
L - знакоместа для букв;
   здесь могут находиться латинские буквы от A до Z;
0 - знакоместа для цифp.
Таким обpазом можно опpеделить 26*26*26*10*10*10=17576000 уникальных кодов. Пpи стаpте Сеpвеp находит код с максимальным значением (если считать, что пеpвые тpи цифpы взяты из 26-pичной системы счисления, а последние тpи - из десятичной). Поpождение новых уникальных номеpов пpодолжается от этого найденного кода. Если опеpация была удалена, то ее уникальный код уже не будет никогда использован (если остались опеpации с б'ольшими значениями уникального кода). Таким обpазом суммаpный pазмеp всех 12-ти (за 12 месяцев) файлов *.f3p не может пpевышать 17576000 записей. Реальный суммаpный pазмеp (с учетом удалений - т.е. пpопущенных уникальных кодов) зависит от хаpактеpа pаботы с пpиложением, но в любом случае - никак не менее нескольких миллионов записей в год.


Исходя из этого 5-6 млн. операций в месяц исчерпают все возможные коды примерно за 3 месяца (никак не за 6), причем при этом невозможно будет работать с таким журналом (ничего не удалить и не создать новых операций без restamp).Скорее всего цифра 5-6 млн. слегка завышена :). Не могу понять почему не воспользовались вариантом с упаковкой документов в данном конкретном случае  :(

В свое время при просчете операций для настройки в режиме 1 операция=1 строка документа из-за такого ограничения пришел к варианту с упаковкой документов в extr.dat c регистрацией 1 операции для проведения документа. С тех пор ни разу не пожалел о своем выборе (единственный раз за 5 лет в этом году не получилось использовать адаптер из-за размера extr.dat, превысившего 2 гб.).
Все операции/документы могут быть сделаны в стандартном clw клиенте (хотя все заказы затягиваются из внешних xml файлов подготовленных в других расчетных программах).


По поводу

Quote:
Quote:
Не могу поверить, что для всех ваших пользователей всегда нужны актуальные данные для продолжения работы Grin

а я немогу поверить что вашым пользователям плевать на то что ктото изменил остатки на складе...

могу сказать, что остатки на складе важны только пользователям, которые "проводят" документы, то есть реально списывают или изменяют остатки на складах. Остальным пользователям-менеджерам, просто набирающим счета заказы клиентов действительно "плевать" сколько чего есть на складе в текущий момент (максимум что важно -  могут предупредить клиента что сейчас товара не хватает и продать что-нибудь другое).
Если у Вас все пользователи списывают-изменяют остатки на складах, то это совсем не означает, что всем им архиважно знать реальный остаток каких нибудь гвоздей на складе в момент набора документа по продаже, например канцтоваров или каких-то продуктов.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Svetlana на 26.11.12 в 13:43:52
...Исходя из этого 5-6 млн. операций в месяц исчерпают все возможные коды примерно за 3 месяца (никак не за 6), причем при этом невозможно будет работать с таким журналом (ничего не удалить и не создать новых операций без restamp).Скорее всего цифра 5-6 млн. слегка завышена...

Нет, здесь все верно, для этого проекта ФБП:синхросерверов было расширено адресное пространство уникальных кодов вот так:

после ZZZ-999 следует AAA0000, AAA0001 ...
после ZZZ0999 следует ААА1000, ААА1001 ...

То есть вместо среднего минуса теперь по-сути 11-ричная цифра.
Теперь может быть до 26*26*26*11*10*10*10 = 193336000 уникальных кода.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Denis, Dnepropetrovsk на 26.11.12 в 15:08:57
Понятно :)
Теперь становится ясно, почему тогда не дошли до упаковки операций.

Я вот сам никак не могу себя заставить прописать очистку базы от прошлогодних документов и расчетов. Сейчас в extrd.dat хранятся все заказы с 2007 г. и их можно просмотреть из любой базы (так же как и подкинуть текущий extrd.dat в любую предыдущую базу). Если не решится вопрос с ограничением 2 гб для extrd.dat в адаптере, похоже все-таки придется удалять устаревшие данные. :(

Иногда ограничения все же полезны ;D. Заставляют искать более оптимальные решения возникающих задач.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем BBBB на 26.11.12 в 15:32:55
Попросите у ХД утилиту e.exe, а может и сами можете ее написать.
Она упорядычевает записи из extrd.dat к читабельному виду *.txt (файл соответственно уменьшается), далее можно просматривать, если обнаружились устаревшие записи - по образцу удалить их со всего extrd.dat, создается обновленный extrd.dat. Весьма удобно и благодарны.  

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем VLV на 26.11.12 в 15:46:57
Вот бы парочку(а то и больше) Extrd.dat иметь. Один для оперативного мусора, другой для долговременных данных. Возникали ситуации когда из-за сбоев при использовании Extrd.dat под временные массивы он рушился и терялись хранимые в нем данные о контрагентах или товарах....ой трудоемкое мучение....даже если всего пару десятков новых товаров введено в базу со времени последнего бэкапа.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Denis, Dnepropetrovsk на 27.11.12 в 10:46:46

on 11/26/12 в 15:46:57, VLV wrote:
Вот бы парочку(а то и больше) Extrd.dat иметь. Один для оперативного мусора, другой для долговременных данных. Возникали ситуации когда из-за сбоев при использовании Extrd.dat под временные массивы он рушился и терялись хранимые в нем данные о контрагентах или товарах....ой трудоемкое мучение....даже если всего пару десятков новых товаров введено в базу со времени последнего бэкапа.


Хмм..  а о каких сбоях идет речь?
Поначалу тоже боялся что будут сбои с extrd.dat,  но за пять лет ни разу extrd.dat не слетал (тьфу тьфу). Acnt.a3p  регулярно из acnt.bak восстанавливаю, так как большой очень 420мб  долго перезаписывается при изменении..

C extrd.dat  работаю всегда в режиме fastged (так как в нем храню документы и временные данные для рабочих форм без fastged скорость выполнения форм падает на порядок).


Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Iamik на 27.11.12 в 11:57:03

on 11/27/12 в 10:46:46, Denis, Dnepropetrovsk wrote:
Acnt.a3p  регулярно из acnt.bak восстанавливаю, так как большой очень 420мб  долго перезаписывается при изменении..

Интересный факт: размер записи acnt.a3p 1565 байт, а реально необходимо только 332 байта, все остальное раскручивается в памяти. То есть ваших 420 Мб вполне могут быть 90 Мб, если изменить процес считывания и записи acnt.a3p   ;)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем VLV на 27.11.12 в 12:04:19

Quote:
Хмм..  а о каких сбоях идет речь?


Отчетные формы у меня строятся через массивы, использующие extrd.dat. Область применения минимаркет...порядка 20000 наименований товаров. В extrd.dat в основном сокращенные наименования, штрихкоды, всего около 100МБ. Цифры в екстра, оперативное ядро в фактах.... Расклад такой что остальные  300-400М extrd.dat заняты под оперативные массивы через которые импортируются продажи из ККМ, строятся формы.
 
Сбои несколько раз возникали видимо из-за вирусов когда шла активная работа по инвентаризации сразу из нескольких клиентов. Сервер вроде не виноват. Но если бы  данные о товарах и "оперативная" память были разделены востанавливать последствия было бы легче.

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем mine-R на 03.12.12 в 21:30:18
В качестве пожелания.
Хотелось бы в компанию к restamp.exe, появления destamp.exe. Нативного,"от создателя"  :)

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем Svetlana на 14.12.12 в 16:24:21
Мы решили сохранить совместимость серверов 4.22 и следующих 4.40 и обновили файлы. В итоге получилось:

НОВОЕ В ВЕРСИИ 4.40:
Введен ключевой файл "stampmod".
Присутствие данного файла обеспечивает полную переиндексацию [stamp 3] операции (если заменить файл операций своим и отправить директиву "p mc=", то сервер полностью корректно перечитает операции, которые он не создавал или не удалял).

Ссылки:
ФБП:сервера 32-х разрядные v. 4.40:
http://www.hdru.com/russian/fnt2-32-440.exe  
http://www.hdru.com/russian/fnt5-32-440.exe  
http://www.hdru.com/russian/fnt10-32-440.exe  
http://www.hdru.com/russian/fnt20-32-440.exe  
http://www.hdru.com/russian/fnt30-32-440.exe  
http://www.hdru.com/russian/fnt50-32-440.exe  

ФБП:сервера 64-х разрядные v. 4.40:  
http://www.hdru.com/russian/fnt5-64-440.zip  
http://www.hdru.com/russian/fnt10-64-440.zip  
http://www.hdru.com/russian/fnt20-64-440.zip  
http://www.hdru.com/russian/fnt30-64-440.zip  
http://www.hdru.com/russian/fnt50-64-440.zip

Заголовок: Re: Нестандартное использование Сервера ФБП
Прислано пользователем MELVIS на 14.12.12 в 18:04:26
Большое спасибо от команды MELVIS !!!



Powered by YaBB 1 Gold - SP 1.3.2!
Forum software copyright й 2000-2004 Yet another Bulletin Board