Форум бухгалтеров и предпринимателей Узбекистана

[Aktmx]

у меня вопрос о разделение базы в 1С 7.7: есть база 1С 7.7 Бух.учет, работает нормально, только при выгрузке занимает немного времени(примерно 10 мин), иногда и при формирование отчетов за длительный период, так вот как часто нужно разделять базы? Заранее спасибо...

[Abdurohman]

[Aktmx]

А перевести базу в Windows Server + SQL Server не пробовали?[/quote]

база уже находиться на этом сервере, главный бухгалтер ставит задачу разделение базы, хотел бы узнать по этому поводу подробнее, в каких случаях следует разделять базу, может это связано с общим объемом базы???

[Abdurohman]

[Умида]

[Aktmx]

[Умида]

Ну, например, по годам: 2010-2012, 2013-2015

[Aktmx]

[Абдуллоева Раъно]

Думаю речь идет о свертке. Если действительно у Вас SQL то не должно открываться 10 минут. Подозроеваю что Вы ошибаетесь насчет SQL.

[Умида]

Во-первых, у Вас на сервере база сидит, пока "места" хватает, зачем ее делить?
Во-вторых, базу делят в случае необходимости, а не по прихоти бух-а.
Например, по годам (прошла проверка, убираем в архив), по компаниям и прочим подобным ситуациям.
А вообще, базу свертывают, архивируют и тд и тп и начинают новую.
Как видите, кричащих моментов для разделения баз нет.

[Aktmx]

[Aktmx]

[Умида]

[Abdurohman]

Вот, нашел ответ как это делается и что будет.

Во время командировки на подшефное предприятие (входит в наш холдинг, городок довольно далеко от столицы, место действия - Украина) местные попросили помочь с переносом БД 1С 7.7 на другой сервер.
1С 7.7 оперативный учет + бухгалтерия, БД в DBF, 1.7 гига, инфа с 2004 г., конфигурация нетиповая (!), целиком самописная, писанная местными "светилами" и обслуживаемая ими же.
Конфигурация ведет бухучет и зп (частично, компоненты расчета не было).

Причина переноса - выход из строя старого сервера. Он представлял собой обычный старый ПК, на плате вздулись конденсаторы, перенос был объяснен так: "...в процессе каждодневной переиндексации (!) БД 1С зависает...".

За неделю до нашего приезда силами местного ИТ отдела (не знакомого с 1С вообще) на другом сервере была запущена 1С в портейбл версии и перенесена сама база (путем копирования ее каталога), однако бухов не устраивало то, что в этом варианте не проходит авторизация пользователей (при запуске не требует пароль).

Нами была установлена комплексная 1С с 25-ми бинарниками, при запуске потребовалась переиндексация в монопольном режиме. После успешного запуска на всякий случай было предложено провести тест БД (режим "Тестирование").
Все выполнялось в присутствии главного бухгалтера.

Тест затянулся на несколько часов, в процессе теста было выявлено несколько ошибок усечения текстового реквизита документов ПН (неопасные, комментарии), неразрешенная ссылка в двух документах на несуществующий справочник (судя по названию "Ситуации" - вспомогательный), изменение времени нескольких ПН документов, а также весьма множественные ошибки отстутствия связей с несколькими типами документов ЗП за довольно старый период. Последнее было на месте объяснено гл. бухом как "... нам тогда-то урезали базу за два года (2004-2005), больше ошибок в ходе тестирования выяслено не было. По результатам на всякий случай весь вывод тестирования был сброшен в текстовый файл для спецов местного франчайзи, писавшего конфу.

Через день после событий бухгалтерия обнаружила значительные расхождения по сальдо счетов и управленческому учету. Ближайшая резервная копия была недельной давности.
Местный франч по данному факту только развели руками и сказали что-то невразумительное в духе "вроде как не должно было такое быть, но все бывает...", они предложили не исправлять текущую БД, а откатиться на копию из бэкапа, чтоби было сделано.

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

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

Хотя с другой стороны, как же они будут при таком раскладе дальше жить с такой "странной" БД и верить ее результатам...