CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
Стучаться в техподдержку. Ситуация нестандартная, вряд ли кто то знает ее решение, кроме разработчика.
Цитата: Risa від Червень 05, 2012, 16:40:49
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
А что это за скрипт у вас создает домен который был в программе с первого дня ее запуска? А вообще с такими вопросами конечно на поддержку с описанием что вы делаете.
Цитата: Risa від Червень 05, 2012, 16:40:49CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
у мене схожа ситуація:
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.SQL error state =23000
Unsuccessful metadata update.
CREATE DOMAIN TKOLVO failed.
Violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_2" on table "RDB$FIELDS".
Problematic key value is ("RDB$FIELD_NAME" = 'TKOLVO').
Як тоді вирішили?
Цитата: majachok від Жовтень 19, 2024, 10:57:43Цитата: Risa від Червень 05, 2012, 16:40:49CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
у мене схожа ситуація:
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.SQL error state =23000
Unsuccessful metadata update.
CREATE DOMAIN TKOLVO failed.
Violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_2" on table "RDB$FIELDS".
Problematic key value is ("RDB$FIELD_NAME" = 'TKOLVO').
Як тоді вирішили?
Після якого скрипта чи після яких змін в програмі це з'явилось?
Цитата: molotokk від Жовтень 19, 2024, 21:13:06Цитата: majachok від Жовтень 19, 2024, 10:57:43Цитата: Risa від Червень 05, 2012, 16:40:49CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
у мене схожа ситуація:
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.SQL error state =23000
Unsuccessful metadata update.
CREATE DOMAIN TKOLVO failed.
Violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_2" on table "RDB$FIELDS".
Problematic key value is ("RDB$FIELD_NAME" = 'TKOLVO').
Як тоді вирішили?
Після якого скрипта чи після яких змін в програмі це з'явилось?
Справа в тому, що ніяких скриптів у програмі не було. Стандартна процедура БЕКАП і потім еопіювання на ФТП-сервер. Причому перевірив на всяк випадок у інших клієнтів - все відновлюється! А тут помилка..... ще чомусь пише при відновлнні, що виявлена стара БД, - але у серпні лише накатував скрізь по еомпам на точці версію 7.91.2
Цитата: majachok від Жовтень 20, 2024, 10:35:14Цитата: molotokk від Жовтень 19, 2024, 21:13:06Цитата: majachok від Жовтень 19, 2024, 10:57:43Цитата: Risa від Червень 05, 2012, 16:40:49CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
у мене схожа ситуація:
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.SQL error state =23000
Unsuccessful metadata update.
CREATE DOMAIN TKOLVO failed.
Violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_2" on table "RDB$FIELDS".
Problematic key value is ("RDB$FIELD_NAME" = 'TKOLVO').
Як тоді вирішили?
Після якого скрипта чи після яких змін в програмі це з'явилось?
Справа в тому, що ніяких скриптів у програмі не було. Стандартна процедура БЕКАП і потім еопіювання на ФТП-сервер. Причому перевірив на всяк випадок у інших клієнтів - все відновлюється! А тут помилка..... ще чомусь пише при відновлнні, що виявлена стара БД, - але у серпні лише накатував скрізь по еомпам на точці версію 7.91.2
А не може бути бекап пошкоджений? Наприклад-вимкнуло комп швидше чим зробився бекап?
Цитата: matiashi від Жовтень 20, 2024, 20:49:27Цитата: majachok від Жовтень 20, 2024, 10:35:14Цитата: molotokk від Жовтень 19, 2024, 21:13:06Цитата: majachok від Жовтень 19, 2024, 10:57:43Цитата: Risa від Червень 05, 2012, 16:40:49CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.
и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?
у мене схожа ситуація:
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION
DataM.sScript:
This operation is not defined for system tables.SQL error state =23000
Unsuccessful metadata update.
CREATE DOMAIN TKOLVO failed.
Violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_2" on table "RDB$FIELDS".
Problematic key value is ("RDB$FIELD_NAME" = 'TKOLVO').
Як тоді вирішили?
Після якого скрипта чи після яких змін в програмі це з'явилось?
Справа в тому, що ніяких скриптів у програмі не було. Стандартна процедура БЕКАП і потім еопіювання на ФТП-сервер. Причому перевірив на всяк випадок у інших клієнтів - все відновлюється! А тут помилка..... ще чомусь пише при відновлнні, що виявлена стара БД, - але у серпні лише накатував скрізь по еомпам на точці версію 7.91.2
А не може бути бекап пошкоджений? Наприклад-вимкнуло комп швидше чим зробився бекап?
все можливо....і пошкоджені всі за останні декілька місяців...
але питання в іншому: що можна зробити? Хтось з цим стикався?
Несправедливо було не вказати на форумі, те що "сервер було атаковано вірусом - шифрувальником"
Це перенаправлений лист:
Від: Служба підтримки
Кому: majachok
Дата: 21 жовтня 2024 р., 9:39:41
Тема: ! ТЕРМІНОВО! Треба допомога! Проблеми з відновленням бази даних з резервної копії
===8<==============Оригінал тексту листа================
Вітаю,
Є більш старі резерви? Дуже схоже що файл резерву пошкоджений.
Яка ОС була на Сервері і яка точно версія Firebird?
19.10.2024 в 8:51, Ви звертались:
> Добрий день!
> Треба допомога.
> Проблеми з відновленням бази даних з резервної копії
> У клієнта встановлена була мережева версія програми 7.91.2 від 16.07.2024
> Система налаштована так що кожен день о 23 годині робилась резервна
> копія бази на відправлялася на ФТП сервер. О о годин 36 хв сервер
> було атаковано вірусом - шифрувальником.
> Я вирішив скачати бекап та розвернути на локальному ПК. Але від час
> відновлення було виявлено помилку. Допоможіть вирішити проблему.
> файли резервних копій бази за посиланням
...
--
Служба підтримки
http://www.softbalance.com.ua
===8<===========Кінець оригіналу тексту листа===========
Цитата: admin від Жовтень 21, 2024, 10:14:39Несправедливо було не вказати на форумі, те що "сервер було атаковано вірусом - шифрувальником"
Це перенаправлений лист:
Від: Служба підтримки
Кому: majachok
Дата: 21 жовтня 2024 р., 9:39:41
Тема: ! ТЕРМІНОВО! Треба допомога! Проблеми з відновленням бази даних з резервної копії
===8<==============Оригінал тексту листа================
Вітаю,
Є більш старі резерви? Дуже схоже що файл резерву пошкоджений.
Яка ОС була на Сервері і яка точно версія Firebird?
19.10.2024 в 8:51, Ви звертались:
> Добрий день!
> Треба допомога.
> Проблеми з відновленням бази даних з резервної копії
> У клієнта встановлена була мережева версія програми 7.91.2 від 16.07.2024
> Система налаштована так що кожен день о 23 годині робилась резервна
> копія бази на відправлялася на ФТП сервер. О о годин 36 хв сервер
> було атаковано вірусом - шифрувальником.
> Я вирішив скачати бекап та розвернути на локальному ПК. Але від час
> відновлення було виявлено помилку. Допоможіть вирішити проблему.
> файли резервних копій бази за посиланням
...
--
Служба підтримки
http://www.softbalance.com.ua
===8<===========Кінець оригіналу тексту листа===========
Можливо несправедливо , що не сказав про вірус. Але останній Бекап було створеноо 23 годині 18-10-24року. а атаковано сервер вірусом о 0-30 год 19-10-24року.
ВИбачаюсь. Вірус бекапи не "побив", бо кожного дня бекап копіюється на ФТП-сервер. (це наразі ледве не єдиний спосіб запобігти зараженню бази) . Але оскільки я не зміг розвернути і попередні бекапи, - то грішу на "неякісну" або порчену базу. Терміново перевірив усі бази клієнтів. У всіх все працює. Бекап робиться однаковим скриптом. Щось я тут упустив.
я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.
https://ibb.co/N7Kt91H
Цитата: matiashi від Жовтень 21, 2024, 12:55:57я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.
https://ibb.co/N7Kt91H
Дякую за пораду!
Перегляну дану програму.
АЛЕ:
Утиліта GBAK тим і відрізняється від інших засобів (упаковщиків архіваторів), що вона робить резервну копію бази у фоновому режимі. Навіть коли користувачі підключені до БД. Але виявилося, що з файлу %backup%.fbk не можна відновити таблиці з товарами, накладними тощо.... на відміду від файла sklad.tcb.
Тепер приходжу до висновку, що все ж таки треба було архівувати і файл sklad.tcb і відправляти на ftp-server а не тільки резервну копію. Правда доведеться перед цим перезавантажити сервер, щоб "відвалити всіх користувачів від бази"
До речі... перевірив резервні копії інших клієнтів,- все піднімається!!!!! бази працюють!
Якщо є ще пропозиції стосовно бекапів, і утіліт - пропонуйте. Не використовуйте хмари типу GoogleDrive!!!! Якщо згорів комп, чи щось подібне, - то це вас врятує! Якщо вірус-Шифрувальник то файли на хмарі теж будуть зашифровані! це перевіриний ФАКТ!
Цитата: majachok від Жовтень 21, 2024, 16:42:08Цитата: matiashi від Жовтень 21, 2024, 12:55:57я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.
https://ibb.co/N7Kt91H
Дякую за пораду!
Перегляну дану програму.
АЛЕ:
Утиліта GBAK тим і відрізняється від інших засобів (упаковщиків архіваторів), що вона робить резервну копію бази у фоновому режимі. Навіть коли користувачі підключені до БД. Але виявилося, що з файлу %backup%.fbk не можна відновити таблиці з товарами, накладними тощо.... на відміду від файла sklad.tcb.
Тепер приходжу до висновку, що все ж таки треба було архівувати і файл sklad.tcb і відправляти на ftp-server а не тільки резервну копію. Правда доведеться перед цим перезавантажити сервер, щоб "відвалити всіх користувачів від бази"
До речі... перевірив резервні копії інших клієнтів,- все піднімається!!!!! бази працюють!
Якщо є ще пропозиції стосовно бекапів, і утіліт - пропонуйте. Не використовуйте хмари типу GoogleDrive!!!! Якщо згорів комп, чи щось подібне, - то це вас врятує! Якщо вірус-Шифрувальник то файли на хмарі теж будуть зашифровані! це перевіриний ФАКТ!
Та це зрозуміло, що при синхронізації з гугл диском, шифрувальщик все поб'є. Я про сторонній софт говорив, він робить наступне, бере архівує вказану папку(я вибрав архівувати з паролем), а далі, цей архів він відсилає будь куди, чи на гугл диск(повторюся, не синхронізація через гугл диск) або на ФТП, доречі відправляти на ФТП без пароля дуже небезпечно з точки зору захисту інформації, так як протокол ФТП не шифрується. Все дуже просто, вже працює роками..... Раз налаштував і забувся, якби не бухгалтер зі своїм бухгалтерским софтом, то взагаліб не було роботи. А про синхронізацію, на гугл диск-раз виручила, не прийшлося терміново їхати на магазин, коли вмер БЖ в компі, 15хв, все розвернулося на іншому компі. Для себе зробив висновок, що краще все використовувати в комплексі.
Вітаю!
Окрім FTP ще існує SFTP! :)
А стосовно зберігання, - то наче все було збережено... я теж думаф, що зараз за 15 хв розверну базу на іншому компі.... от саме база і не розвернулася (хоча логи по бекапу були нормальні).
Зробив висновок:
автоматизація - то тобре, але іноді теба з певною періодичністю перевіряти чи бекап можна підняти!!!
Згодний, все потребує уваги.
Цитата: matiashi від Жовтень 21, 2024, 12:55:57https://ibb.co/N7Kt91H
Якась фігня.... у вас може 1С встановлено?
Цитата: majachok від Жовтень 21, 2024, 16:42:08Цитата: matiashi від Жовтень 21, 2024, 12:55:57я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.
https://ibb.co/N7Kt91H
Дякую за пораду!
Перегляну дану програму.
АЛЕ:
Утиліта GBAK тим і відрізняється від інших засобів (упаковщиків архіваторів), що вона робить резервну копію бази у фоновому режимі. Навіть коли користувачі підключені до БД. Але виявилося, що з файлу %backup%.fbk не можна відновити таблиці з товарами, накладними тощо.... на відміду від файла sklad.tcb.
Тепер приходжу до висновку, що все ж таки треба було архівувати і файл sklad.tcb і відправляти на ftp-server а не тільки резервну копію. Правда доведеться перед цим перезавантажити сервер, щоб "відвалити всіх користувачів від бази"
До речі... перевірив резервні копії інших клієнтів,- все піднімається!!!!! бази працюють!
Якщо є ще пропозиції стосовно бекапів, і утіліт - пропонуйте. Не використовуйте хмари типу GoogleDrive!!!! Якщо згорів комп, чи щось подібне, - то це вас врятує! Якщо вірус-Шифрувальник то файли на хмарі теж будуть зашифровані! це перевіриний ФАКТ!
Гуглдиск зберігає до 10 останніх варіантів файлу, і шифрувальник псує тільки останню версію файлу, яка йде на гуглдиск при синхронізації. Що заважає відновити попередній варіант робочого файлу? По мені гуглдиск найкращий з безкоштовних варіантів бекапів
не згоден! Маю інший негативний досвід. GD шифрує все!
Цитата: majachok від Жовтень 24, 2024, 18:46:57Цитата: matiashi від Жовтень 21, 2024, 12:55:57https://ibb.co/N7Kt91H
Якась фігня.... у вас може 1С встановлено?
Ні, то скрін з сервера з Укрсклада, но вона і під 1С підходить....
Цитата: Proz72 від Жовтень 25, 2024, 11:39:34Цитата: majachok від Жовтень 21, 2024, 16:42:08Цитата: matiashi від Жовтень 21, 2024, 12:55:57я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.
https://ibb.co/N7Kt91H
Дякую за пораду!
Перегляну дану програму.
АЛЕ:
Утиліта GBAK тим і відрізняється від інших засобів (упаковщиків архіваторів), що вона робить резервну копію бази у фоновому режимі. Навіть коли користувачі підключені до БД. Але виявилося, що з файлу %backup%.fbk не можна відновити таблиці з товарами, накладними тощо.... на відміду від файла sklad.tcb.
Тепер приходжу до висновку, що все ж таки треба було архівувати і файл sklad.tcb і відправляти на ftp-server а не тільки резервну копію. Правда доведеться перед цим перезавантажити сервер, щоб "відвалити всіх користувачів від бази"
До речі... перевірив резервні копії інших клієнтів,- все піднімається!!!!! бази працюють!
Якщо є ще пропозиції стосовно бекапів, і утіліт - пропонуйте. Не використовуйте хмари типу GoogleDrive!!!! Якщо згорів комп, чи щось подібне, - то це вас врятує! Якщо вірус-Шифрувальник то файли на хмарі теж будуть зашифровані! це перевіриний ФАКТ!
Гуглдиск зберігає до 10 останніх варіантів файлу, і шифрувальник псує тільки останню версію файлу, яка йде на гуглдиск при синхронізації. Що заважає відновити попередній варіант робочого файлу? По мені гуглдиск найкращий з безкоштовних варіантів бекапів
Підтримую, у гугла є управління версіями і можна скачати передостанню версію.
https://ibb.co/5xZDRLM