Форум ГК "СтройСофт"

lexx2 писал(а):вы находитесь в Москве, так что вам даже проще довести данную проблему до программистов путем телефонного разговора с консультантом, и все ваши замечания вы можете им отправить на эл. почту т.е. на support.

arbeiten писал(а):По поводу ошибок стоит ждать ответа?

да и про это

arbeiten писал(а):А вас все хорошо?

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

Опечатка в наименовании расценки ТСН 3.15-67-4 вместо слова "СТЯЖКА" написано слово "ГРУНТ" и т.д. см. также расценку 15-67-3

Это опечатка разработчика ТСН-2001, расценка не менялась с момента выхода базы ТСН-2001

В смете отображается количество, как равное 1, а фактически 0,9999997 - видно на скриншоте.
Заметил, только когда распечатал смету.

Как сделать, чтобы в смете отображалось фактическое значение без округления?

Добрый вечер. только начинаю работать со сметой. Пока я 0. Подскажите пожалуйста ПРОСТОЙ вопрос,как переименовать папку, правой кнопкой мыши вызываю чудо окошко, в котором у меня при клике на строку переименовать ни чего не происходит, не вбивается новое название.

Когда нажимаешь расширить или уменьшить окно - то это применяется ко всем открытым окнам((((

Ошибка, пришлось закрывать через диспетчер задач.

На ответ со стороны Администрации все еще надеюсь))

arbeiten писал(а):Ошибка, пришлось закрывать через диспетчер задач.

На ответ со стороны Администрации все еще надеюсь))

Вы вроде уже не первый день на форуме, какие действия предшествовали данной ошибке ?

expert69, какие действия не запомнил.

Баг с обнулением объемов подчиненных строк
Давно заметил баг с обнулением объемов на подчиненные строки (почему особенно это касается расценок на монтаж дверей и порожки , радиаторы,
3.10-73-1
3.11-39-1
3.18-6-2

Сегодня поймал момент, когда это произошло. Удалил индексы по объекту из текущих цен, загрузил актуальные, после этого объемы подчиненных строк этих позиций обнулились.

Откуда это берется???

Такая фигня после копирования объекта происходит((((((((((((

При копировании объекта вообще объемы часто изменяются, округляются, обнуляются((((((((

При рестарте получил неожиданное сообщение в системный журнал "Служба Stroysoft Search Manager зависла при запуске". Сама служба работает нормально. При просмотре обнаружил, что служба не имеет зависимостей - хотя должна зависеть как минимум от службы сервера БД.
Какие ещё зависимости должны быть у этой службы? восстановить руками не проблема, но надо знать, что восстанавливать.

Akina писал(а):Какие ещё зависимости должны быть у этой службы?

На данный момент никаких.

Fray писал(а):На данный момент никаких.

Так... Значит, возникает вопрос - а откуда проблема?

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

Если зависимость (фактическая) всё-таки существует, но просто не устанавливается инсталлятором серверной части - нельзя ли всё-таки узнать, какие сервисы из устанавливаемых ДОЛЖНЫ работать, чтобы менеджер поиска работал? я понимаю, что служб не так много, и можно тупо заняться перебором - но очень не хочется заниматься этим на боевом сервере. И лишнего в зависимости ставить тоже некошерно...

Что делать-то?

Akina писал(а):Так... Значит, возникает вопрос - а откуда проблема?

Суть в том, что мы знаем об этой проблеме. И вы вполне вероятно правы, что добавление зависимости от службы сервера БД поможет решить ее. Но, к сожалению, гарантировать на 100%, что данное действие избавит от этой проблемы, не могу.

Fray писал(а):На данный момент никаких.

всего лишь значит что я не могу точно ответить Вам именно на данный момент . Вы можете попробовать добавить зависимость от службы сервера БД (Firebird), но это на свой страх и риск (хотя я думаю, что все пройдет хорошо).

Fray писал(а):Вы можете попробовать добавить зависимость от службы сервера БД (Firebird), но это на свой страх и риск (хотя я думаю, что все пройдет хорошо).

То, что наличие зависимости не должно ухудшить положения дел (в данном случае это приведёт всего лишь к 2 изменениям - установит жёстко порядок старта сервисов и введёт связку при остановке/рестарте сервисов), у меня особых сомнений не вызывает. Просто понять бы логическую зависимость между сервисами.

Вообще ПО устанавливает (если ошибаюсь - поправьте) 4 сервиса:

1) Сервис сервера БД (Firebird Server - Default Instance)
2) Сервис обслуживания (Stroysoft IB Backup Service)
3) Сервис поиска (Stroysoft Search Engine)
4) Сервис индексирования (Stroysoft Search Manager)

При этом второй зависим от первого, а вот третий и четвёртый висят в воздухе... хотя по смыслу они как минимум должны общаться с БД, а, значит, с FB-сервером. Третий, к тому же, интерактивен - во всяком случае, слушает порт 3315, четвёртый же не жаждет общаться с внешней средой.

Не сильно вдаваясь в то, чем эти два сервиса занимаются, чисто на общих, предполагаю, что search manager обеспечивает индексирование для быстрого поиска, а search engine получает от юзеров запросы и по построенным индексам быстренько находит требуемое. Если так, и если индексы хранятся в базе данных (на что, впрочем, намекает и conf-файл), то получается, что каждый из этих двух сервисов должен стартовать уже после того, как FB запустится. И если сервис поиска не полезет к FB, пока его кто-нибудь не спросит, то сервис индексирования сразу цепляется к БД и смотрит, не устарели ли индексы, и не надо ли их освежить - и если FB не запустился ещё, то наступает жестокий облом.

Если описанная мной схема верна, то введение зависимости 3 и 4 служб от 1-й должно снять проблему и вообще чутка добавить комплексу логичности. Посему просто прошу подсказать - верна ли схема? или я в чём-то неправ - тогда поправьте для лучшего понимания...