1. Владислав Чінючін (vcv) 84 16.09.13 21:55 Зараз в темі
Гарантувати зняття копії бази неушкодженою в процесі роботи може тільки сервер баз даних. У вашому випадку, ви просто обманюєте клієнтську програму. І якщо за час зняття архіву користувач вводили в базу документи, "копія" з великою ймовірністю буде пошкодженої.
Якщо у вас SQL-сервер, що заважає зробити гарантовано цілісний бекап бази засобами Sql?
NN2P; Raduga; farhod54; elephant_x; FlagmanGK; u_n_k_n_o_w_n; berezdetsky; bulpi; msvd; andrewks; + 10 - Відповісти
2. Олександр Капустін (kapustinag) 17.09.13 1:07 Зараз в темі
Тим більше що, якщо база клієнт-серверна, значить, розмір її не дуже маленький, а в цьому випадку SQL-бекап зробиться однозначно швидше, ніж вивантаження в DT. І подальша завантаження з SQL-бекапа буде швидше, ніж з DT.
3. Вова Вишина (Tahallus) 421 17.09.13 2:53 Зараз в темі
4. Юрій Юр'єв (yurega) 70 17.09.13 3:42 Зараз в темі
При збереженні бази таким способом, частина інформації, зміненої в процесі вивантаження, може вивантажитися некоректно. З цим згоден. Тому для бекапа бази цей спосіб краще не використовувати.
Мета статті не в тому, що б розповісти як робити бекапи бази 1С. Для цього є стандартні способи. Мета в тому, що б поділитися прийомом роботи з базами на сервері 1С. Може бути, для кого-то це буде корисна інформація.
У моєму випадку була необхідність розгортання тестової файлової бази і потрібен був DT-шник. Для цього завдання такий спосіб підходить.
Якщо оновлювати конфігурацію таким способом, то, швидше за все, база даних не виживе після цього. Краще навіть не пробувати :-)
5. Юрій Осипов (yuraos) 910 17.09.13 6:19 Зараз в темі
забавно,
але описаний фокус з вивантаженням клону бази канает.
---
(4)
а ось оновити конфігурацію просто так на халяву не вдасться.
(див. вкладення)
6. Юрій Осипов (yuraos) 910 17.09.13 6:29 Зараз в темі
(5)
pardon. проканало.
--
не в тому конфигураторе натиснув "оновити конфігурацію бази"
--
мабуть плусану
:) - за хакерський склад розуму.
7. Дмитро Кишкин (DmitryKishkin) 17.09.13 7:17 Зараз в темі
На попередній роботі робив так, теж для отримання файлової. Ставив Postgres до себе на локальну машину. Кста, застосовував для поновлення (було дуже багато дрібних типових баз, при "нормальному" оновленні пам'ять на серваке швидко фрагментований - юзера скаржилися на уповільнення роботи). Став оновлювати "через себе" - скарги пройшли. Тільки треба акуратно вигнати користувачів з "основний" бази перед оновленням конфігурації.
Була ще одна думка - не встиг випробувати (роботу змінив ;-)). Що якщо "сервер" на своїй машинці запускати з ключем -debug. Чи не дозволить це нормально налагоджувати серверні модулі в робочих базах без отримання копій. Може, хто пробував.
8. Дмитро Кишкин (DmitryKishkin) 17.09.13 7:23 Зараз в темі
(7) Чуть-чуть описати ;-) Ставив на локальну машину не Postgres, звичайно, а сервер 1С, і прописував з'єднання з Postgres-базою на серваке ;-)
9. Дмитро Лебедєв (mr.Samuelson) 17.09.13 8:07 Зараз в темі
Сумнівний спосіб якийсь)
10. Іван Іванов (Famza) 80 17.09.13 9:17 Зараз в темі
Нехай спосіб і стриманий, але знати його просто обов'язково - хоча б для того щоб уникнути непередбачених сітуёвін потім. +1
11. Євген Пономаренко (Evgen.Ponomarenko) 511 17.09.13 9:44 Зараз в темі
(10) Famza,
Спосіб, не тільки хакерський, але і дуже стриманий! (Хоча за ідею +).
По-перше, вивантажений таким чином DT, може містити не узгоджені дані.
По-друге, можна легко нарватися на непередбачуване поведінки SQL серверів різних виробників, під різні OS. Ефект, на тлі величезних обсягів даних, може перевершити будь-які Ваші очікування.
По-третє, можна банально промахнутися і накосячіть замість тестової бази в бойовий, з причини відсутності контролю тієї самої горезвісної "монопольності".
Надійніше користуватися стандартними механізмами SQL для створення резервних копій на льоту. Або розгортати нічну копію базу в тестовий екземпляр і в ручну переносити оперативні дані.
12. Іван Іванов (Famza) 80 17.09.13 10:09 Зараз в темі
(11) Evgen.Ponomarenko, я не той самий зміст в (10) висловив? Тоді спасибі за розшифровку