Есть 1С 7.7, одна центральная база и 2 периферийных. Периодически возникают проблемы с синхронизацией между ними — например 2 базы видят какой-то документ, а в третьей его нет. Либо документ есть, а движения в регистрах не произошли.
Такое решалось перепроведением документов и восстановлением последовательности. Хотя в теории 1С должна контролировать целостность и т.п. Базы у нас синхронизируются каждые 5-10 минут, объем передаваемых данных небольшой.

Сейчас вот новая ошибка — разные базы видят разные остатки в регистре Деньги по разным кассам. А это уже, в зависимости от ошибки, можно принять за недостачу у кассира.

Вопрос вот в чем: как сделать так, чтобы все было хорошо и все три базы были идентичны? Если это не реально, то как хотя бы оперативно отслеживать проблемы?

1. обмен точно типовой и полный? никаких доп ДЛЛ нет?
2. что такое коллизии слышал?

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

скорее всего коллизии. УРБД надежнейшая вещь, если разумеется учитывать возможность коллизий и грамотно разграничивать права доступа.

Обмен типовой, стандартной компонентой. Дополнительно добавлена только v7plus.dll. Про колизии слышали, но не похоже на них.

Ситуация такая: есть 3 магазина, у каждого магазина свой пользователь "кассир", у которого отдельный журнал РасходныеРозничныеXX и, соответственно, отдельный документ РасходнаяРозничнаяXX. Доступ к этим документам есть только у кассиров (и только к документам своего магазина) и у меня.

Проблем нашел 4 штуки за 3 года. 3 проблемы такого плана - периферийная база создала документ на 10 грн, а в центральной по нему стоит движение 20 грн, хотя есть открыть документ, там будет указана Сумма 10 грн.
И одна проблема - документ в периферийной базе есть, а в центральной его нет.
Документы удалил и провел их копии. Проблема с разными остатками по кассе решилась.

Вопрос почему это происходит и как этого избежать остается.

Размеры баз не приблизились к гигу? Обмен начинает глючить самым первым.

Как считать объем базы? С индексами у меня 1.9 гиг, сами ДБФ на 1.5 гига

В 1С каждая ДБФ-ка с родными дровами не должна превышать 1 Гиг, фактически еще меньше. Кури "проблему 1Гбайт"

Тогда мне еще рано, самая большая dbf - 381mb

(4): это как?.. периферийки 2 - а магазина 3???

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

Если базы ДБФ, то возможны проблемы с индексами, отсюда следуют проблемы с данными в базах.

(10) - грубое нарушение регламента использования урбд; лечение - перезапись всех объектов в базах-источниках с полным обменом.

(9): это я имел в виду 2 периферийных + 1 центральная база.

(10): что за восстановление базы из архива? Базы синхронизируются каждые 5 минут через дропбокс стандартным способом.

(11): Избежать проблем с индексами как-то можно?

(12): что вы имеете в виду?

(13) увы, только перейдя на SQL

Читай лог, ищи коллизии.

Не слушай студентов! Коллизии не вызывают расхождение данных в переферийных базах. Правило простое - кто первый оказался в центре - того и тапки.
Указанная симптоматика говорит о ручных игрищах с регистрацией обменов или повреждением табличек/итогов.

(16): или все нафиг, центр главнее всех.

(17) Центр в центре по определению быстрее всех :)

(18): "центр в центре" кроме того если будет иметь корректировки по объекту, созданному в периферийке, то все остальные изменения, приехавшие в центр - идут лесом вне зависимости от того, "чьи тапки" - вот об чом я.

(0) Отказаться от УРБД, 1 база, остальные по RDP

(20) круто, чо

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

(16): я вот тоже на счет колизий сомневаюсь. А что значит "ручные игрища с итогами"? Повреждения таблиц? Каждый вечер принудительно переиндексация идет по всем базам. А тестирование и исправление делаю очень редко.

(23) "сбой итогов" - довольно обыденная вещь и без "игрищ".

(23): Способы лечения/обнаружения есть?

Для сиквела - валом. Равно как и оперативного исправления.
а т.к. файловые базенки - мелкие, то для них отдельно что-то придумывать - обломно

Мне в голову только одно решение пришло. Раз в день запускается обработка, которая для каждой локальной базы считает суммарный итог по регистрам и записывает это в спец.документ "колизии".

А у администратора 1С при входе будет проверка на идентичность итогов во всех документах за определенную дату. У меня так сейчас регистр "взаиморасчеты" проверяется. Надо, видимо, и остальные регистры добавить.

(27) лучше напиши контроль итогов.

судя по всему проблемы не в урбд а в самих базах. Лечится переводом на SQL но будет снижение производительности

(28): что вы имеете в виду?

(30) контроль правильности итогов регистров.

(31): и как это делается в двух словах?

(0) Вопрос - а в переферийках много народу?

(33): в одной пара человек сидит, от нее проблем и нету. А во второй до 11 человек.

(34) А может проще УРИБ заменить доступом по РДП? 11 человек это прибл. 2-5 мб/сек интернета. 2 человека - им даже 3Ж хватит если он будет стабильным (512-1 мб/сек).

+(35) Как вариант vpn + rdp

Вот вам и будут нынче модные облака )

(35): это если вы не торопитесь, а если у вас очередь клиентов, а у провайдера проблема на линии, или на центральной базе отключили свет?

(38) У нас просто эти белогривые лошадки есть. Но канает, согласен если есть нормальное соединение. Но может нормальный интернет уже дополз до вас?

(39): нормальный интернет давно есть, повторюсь, не хочется увеличивать риски. Потому что если можно работать локально, зачем добавлять еще риск отказа у провайдера и у РЭС?

(35) предлагать магазину работать через РДП - изврат.
(32) взять остатки за предыдущий период, прибавить обороты - и результат сравнить с остатками на текущий период. совпали - замечательно. не совпали - значит, ашипка.

последовательность восстанавливаете? Где восстанавливаете?
какие настройки миграции последовательностей?

(0) Для DBF 7.7 Ежедневное ТиИ со всеми галками в режиме "только тест" снимает проблему неверной арифметики. Скрипт в Планировщик или на Рабочий стол ярлык от него.

пути исправления

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

2. приведение итогов в порядок
блокировка всех баз
полный перерасчет итогов в центре
обмен
полный перерасчет итогов в перефирийках
обмен
установка единой для всех баз границы запрета редактирования
контрольный бекап всех баз
разблокирование всех баз

3. коллизии
устанавливаем запрет редактирования обьектов по признаку "где создался" (документ создался в центре - перефирийки не имеют право править)
запрет редактирования объекта пока он есть в таблицах к обмену (типовые грабли поменяли рекв=1, выгрузили, поменяли рекв=2 выгрузили, загрузили файл с рекв=1 а второй файл потеряли, получили подтверждение что обьект получен)
для уменьшения вероятности потери файлов http://infostart.ru/public/16687/

создание ОЛЕ обработки сравнение итогов между рабочей базой и контрольной на дату запрета редактирования

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

(42) Это пока не надо..

(44) И это пока не надо..

(44) 3. не придет подтверждение второго пакета, объект будет отправлен следующим пакетом.

(48) ты не прав...
удаление из таблицы регистрации не связано с номером пакета, по этому данный сабж критичен для УРБД, а вот в МОД-е данной проблеммы вроде нет...

(49) Как раз связано. Из таблицы регистрации при подтверждении получения пакета удалятся записи с непустым dwnldid значением не меньше подтверждаемого.
при перезаписи объекта при регистрайии ид обмена в таблице регистрации очищается.

(50) в данном случае ты не вник, номер пакета - да, а я говорю о файле обмена

на пальцах

дано: рекв = 1, текПакет=10

центр:
делаем рекв = 2
делаем выгрузку, файл содержит рекв = 2, текПакет=11

перефирийка:
делаем загрузку текПакет=11, рекв = 2
выгружаем подтверждение текПакет=11

этот файл где-то "задержался"....

центр:
делаем рекв = 3
ждем, и не дождавшись подтверждения пакета 11 заново делаем выгрузку
делаем загрузку текПакет=11, рекв = 3
этот файл потерялся на совсем и не дойдет до перефирийки

и вдруг приходит тот самый "задержавшийся файл" который содержит  подтверждение текПакет=11


результат
Центр: рекв = 3, текПакет=11
Перефирийка: рекв = 2, текПакет=11

(51) ты ошибаешься. При повторной выгрузке в ПБ уйдет пакет с №12.
а при изменении в ЦБ реквизита с 2 на 3 - ид пакета очистится. И уйдет объект в обмен со следующим пакетом. поэтому прием пакета с №11 никак не отменит отправку объекта со следующим пакетом.

(52) ты хочешь сказать что если я 534 раза изменю обьект (в течении 1 минуты), то в регистрации будет указано что его нужно выгрузить в текущий+534 номере пакете :)

версионности в 7.7 нет, а вот в 8.х там есть поле версии обьекта, там такой проблеммы нет :)

(53)1. я говорю, что при изменении объекта ид выгрузки в таблице апдейтсов очищается.
а заполняется он при отправке.
поэтому при изменении после отправки он не попадет в подтвержденные.
2. Да? а поле VerStamp - этчо?

>>>при изменении объекта ид выгрузки в таблице апдейтсов очищается. а заполняется он при отправке

убедил :)

(55) "я давно играю"© :-)
просто с использованием этих механизмов у меня сделана универсальная настраваемая даже пользователями миграция. Поэтому и знаю этот механизм достаточно хорошо

(56) посмотреть бы

(57) что именно?
там довольно много