Синхронизация баз

[Аноним]

Вопрос, возможно, очень прост для тех кто этим занимается.
Короче, раньше вел бухалтер на 1С на одном компе. Теперь хочет на двух. Второй, естественно, дома. Как ей выгружать и загружать информацию, чтобы обе базы были синхронны? Т. е.
можно было передовать на дискетах или по модему. Есть ли стандартные средства в 1С или что-то другое?
ПОМОГИТЕ! Простите некомпетентность.

[training1C]

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

Да, конечно, такое средство есть. Причем штатное от 1С. Называется УРБД - управление распределенными базами данных.
Решает именно ваши проблемы (удовлетворяет запросы .
Стоит 480$.

Есть решение от сторонних разработчиков. МОД от ПиБи. Стоит кажется 45 или 60 долларов на комьютер. Точнее не знаю, поэтому ногами не пинать.

Первый вариант мне больше нравится по надежности.

[Юлия М]

По-моему все гораздо проще. Вам надо зайти в конфигуратор, в меню выбрать администрирование, сохранить данные. Указать путь куда сохранять: дискета или жесткий диск, с которого потом перепишете на дискету. Принесете дискету домой, точно также загрузить конфигуратор, меню администрирование, выгрузить данные, указываете путь на дискету. Все, данные выгружены, можно с ними работать. Только потом не забудьте все так же сохранить и отнести на работу!

[training1C]

Юлия М, можно и так, как вы говорите, но только при соблюдении одного правила: Данные вводятся в один момент времени в одном месте. Для бухгалтеров, единолично ведущих учет на предприятии это нормальный вариант. Если же например на фирме действует ночная смена(вечерняя), то не прокатит. ХОтя для исходного постинга это и выход.

[Аноним]

Благодарю Всех, кто ответил.
Но... Все выгруженные данные слишком большой файл.
Хотелось бы ограничить временным интервалом.
А внешние средства дороговаты.

Может еще идей подкините?
Если есть доступ к коду выгрузки, то где он?

[training1C]

О, Юлия М, видите на "дискетку" не вмещается :-).
МОД. 45-60 долларов тоже дороговато?

Уважаемый, Аноним, будет ли вестись работа одновременно в двух базах или по очереди?

Где вы территориально находитесь?

[Аноним]

Территориально - под Магаданом.
А вот работать с базой хотелось бы независимо, (Пусть не параллельно) так чтобы передать не только новые, но и измененые документы, строки в справочниках.

[training1C]

Тады прямая дорога к УРБД. Понятно, что дорого, но лучшего решения нет и пока не предвидится.

[Аноним]

Территориально - под Магаданом.
А вот работать с базой хотелось бы независимо, (Пусть не параллельно) так чтобы передать не только новые, но и измененые документы, строки в справочниках.

[Fosihas]

Купите "Рег", приспособление для внешнего расположения жесткого диска. Это устанавливается на компьютор на работе и дома. По работали на работе, забрали домой, поработали вернули на работу.

[Юлия М]

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

[training1C]

Исходное сообщение Юлия М
А что такое "исходный постинг" понятия не имею.

Исходный постинг - начальное письмо в ветке форума.

[Юлия М]

training1C, спасибо, теперь буду знать!

[Dracosha Andrew]

Я в свой время (в прошлом веке ) работал с УРБД от 1С моё мнение:
1. Попытка ввести универсализм и простоту для пользователя очень сильно ослдожнило администрирование.
2. Как следствие упала надежность и так малонадежного формата.
3. Как не печально альтернативы под 1С всё равно нет.

Отсюда выводы:
1. Обязательно иметь резервную копию конфигурации без УРДБ
2. Тчательно резервировать данные в процессе работы.
3. Постараться вводить информацию используя средства уделенного доступа типа Terminal Server
4. Объедините 1 и 2

[training1C]

Исходное сообщение Dracosha Andrew
Я в свой время (в прошлом веке ) работал с УРБД от 1С моё мнение:
1. Попытка ввести универсализм и простоту для пользователя очень сильно ослдожнило администрирование.
2. Как следствие упала надежность и так малонадежного формата.
3. Как не печально альтернативы под 1С всё равно нет.

Отсюда выводы:
1. Обязательно иметь резервную копию конфигурации без УРДБ
2. Тчательно резервировать данные в процессе работы.
3. Постараться вводить информацию используя средства уделенного доступа типа Terminal Server
4. Объедините 1 и 2

Выводы правильные, но никак не связанные с использованием УРБД.
УРБД очень надежная ("кондовая") и непробиваемая. Сильная защита "от дурака". Работаю с ней с 98 года еще с версии 7.5. Нареканий никаких.

[Dracosha Andrew]

УРБД очень надежная ("кондовая") и непробиваемая

Ню-ню... Это у вас связь хорошая...

Выводы правильные, но никак не связанные с использованием УРБД.

Кстати, советую разобраться с "математематикой" УРБД, что бы не строить иллюзий. То, что не сталкивались с проблемами, это не значит, что их не было... Изначально в систему УРБД не заложено много того, что есть в других аналогичных системах.

[rsfin]

Добрый день!

Присоединяюсь к ответам Чувелёва Андрея.

Синхронизация баз данных, как термин и процесс в программировании очень сложен в реализации и выполняется в заказных проектах точно в соответствии с поставленной задачей. И как правило, процесс синхронизации реализуем в одностороннем порядке, т.е. одна из сторон (как правило - принимающая данные) является исключительно "читателем" входящих потоков информации. По моему скромному мнению, автора данной темы скорее всего интересует обработка и доступ к данным одним лицом, с использованием разных средств (компьютеров), в разные периоды времени.
И здесь возможны варианты:
1. упаковка и архивация данных с записью на магнитный носитель (скажем CD-RW), распаковка, обработка и обратный процесс на жесткий диск исходного компьютера;
2. организация удаленного доступа к данным, что возможно будет весьма неудобно, небезопасно и очень медленно, поскольку 1С не позволяет организовать визуализацию данных на удаленном компьютере или предоставлять клиенту данные блоками по 40...80...(или более) Кб;

Прошу прощения, а есть-ли в 1С средства автоматической архивации и сброса на магнитный носитель данных? Я что-то такого не нашел в версии 7.7.

С уважением, Виктор.

[Dracosha Andrew]

автоматической архивации и сброса на магнитный носитель данных?

Это делается через ...., простите, конфигуратор.
Добавлю, что универсального решения не существует даже для такого мощного продукта как MS SQL сервер.
Двухсторонний обмен данними не имеет в настоящее время строгого математического аппарата, но если training1C хочет может его разработать и реализовать средствами 1С

[aXeL]

Многие наши клиенты используют схему с сохранением на CD-RW размеченным для пакетной записи ( это может, к примеру, программа Easy CD creator). В пакетном режиме CD диск прозрачен для чтения записи и доступен как обычная дискета.
т.е.:
1) 2 CD-RW драйва:один дома, 2-й на работе
2)И дома и на работе установить программу записи с поддержкой пакетов
3) Разметить диск CD-RW
4) сохранять на него и читать с него из конфигуратора как обычно.
Ограничения такой схемы: можно работать только в одном месте в одно и тоже время( или дома или на работе).

Можно, конечно автоматизировать некоторые действия, но, поверьте, вручную надежней.

[RS]

Добрый всем день!

Полностью согласен с Вашим мнением Андрей!
Если позволите, то некоторые соображения по теме...

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

В общем-то нет проблем по созданию процедуры, которая выполняет обмен данными между несколькими абсолютно идентичными по формату базами данных. И общеизвестно, что для этого необходим алгоритм присваивающий уникальный номер каждой записи в каждой таблице базы данных. При таком подходе к решению проблемы необходимо выполнить последовательное сканирование таблиц между базами и произвести взаимное добавление (РЕДАКТИРОВАНИЕ, УДАЛЕНИЕ) записей. Но есть несколько НО...
Казалось-бы все просто, но здесь выплывает "на расписном челне" ностальгия по временам, когда программисты боролись за каждый байт в базе данных (сейчас это таблица базы данных) поскольку объемы дисков были маленькие, память дорогая и т.д. и т.п.. В настоящее время железо позволяет не обращать внимание на такие "мелочи", а значит на избыточность данных также никто не обращает внимания. И из этого возникает проблема 1 - время и скорость обмена данными по сети Интернет или обычному телефонному соединению, поскольку цифровые каналы страдают качеством, а выделенка достоточно дорогое удовольствие. При этом пользователь редко понимает, что сервис требует финансовых жертв.
Проблема 2 - синхронизация данных на предмет АКТУАЛЬНОСТИ и АБСОЛЮТНОЙ идентичности содержимого между базами, которая вполне решаема, но позвольте мне не высказывать мнение. Этот вопрос, ИМХО, является (а может и нет) ноу-хау в области технологий и ТЩАТЕЛЬНО охраняется, по понятным причинам, любым программистом или фирмой-разработчиком...

С уважением, Виктор.

Исходное сообщение Dracosha Andrew


Добавлю, что универсального решения не существует даже для такого мощного продукта как MS SQL сервер.
Двухсторонний обмен данними не имеет в настоящее время строгого математического аппарата, но если training1C хочет может его разработать и реализовать средствами 1С