• Ласкаво просимо на Спільнота для обміну досвідом між користувачами програм УкрБланк, УкрСклад, УкрЗарплата.
 

Ошибка не знаю что делать

Автор Risa, Червень 05, 2012, 16:40:49

Попередня тема - Наступна тема

0 Користувачі і 1 Гість дивляться цю тему.

Risa

CREATE DOMAIN TKOLVO AS DOUBLE PRECISION

DataM.sScript:
This operation is not defined for system tables.Unsuccessful metadata update.
STORE RDB$FIELDS failed.

и все труба. загрузится немогу. обновила полностью. но я так понимаю проблема в базе. что делать?

victorpolo

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

admin

Цитата: Risa від Червень 05, 2012, 16:40:49
CREATE DOMAIN TKOLVO AS DOUBLE PRECISION

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

majachok

Цитата: 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

Цитата: 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').

Як тоді вирішили?

Після якого скрипта чи після яких змін в програмі це з'явилось?
підбір та продаж обладнання для торгівлі, допомога в налаштуваннях програми ⇒ "komfort-m.com" ⇒ "t.me/komfortmservice" ⇒ ✆ 097-873-59-01

majachok

Цитата: 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

Цитата: 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
А не може бути бекап пошкоджений? Наприклад-вимкнуло комп швидше чим зробився бекап?
0674614593

majachok

Цитата: 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
А не може бути бекап пошкоджений? Наприклад-вимкнуло комп швидше чим зробився бекап?
все можливо....і пошкоджені всі за останні декілька місяців...
але питання в іншому: що можна зробити? Хтось з цим стикався?
Теорія, - це однозначно треба, але на практиці, щось може бути не так! :-)

admin

Несправедливо було не вказати на форумі, те що "сервер було атаковано вірусом - шифрувальником"

Це перенаправлений лист:
Від: Служба підтримки
Кому: 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<===========Кінець оригіналу тексту листа===========

majachok

#9
Цитата: 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року.
ВИбачаюсь. Вірус бекапи не "побив", бо кожного дня бекап копіюється на ФТП-сервер. (це наразі ледве не єдиний спосіб запобігти зараженню бази) . Але оскільки я не зміг розвернути і попередні бекапи, - то грішу на "неякісну"  або порчену базу.  Терміново перевірив усі бази клієнтів. У всіх все працює. Бекап робиться однаковим скриптом. Щось я тут упустив.
Теорія, - це однозначно треба, але на практиці, щось може бути не так! :-)

matiashi

#10
я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.

https://ibb.co/N7Kt91H
0674614593

majachok

Цитата: matiashi від Жовтень 21, 2024, 12:55:57я стандартними засобами не робив бекап жодного разу, бо чекати коли хтось закриє вікно програми це не раціональне рішення. Є купа софта, який запаковує база данних до архіву і розсилає куди треба(ФТП, Гугл диск та інше), час запуску і періодичність налаштовується індивідуально. Від себе добавлю, що бекапи потрібно робити мінімум в 3 разні місця, для наданості.

https://ibb.co/N7Kt91H
Дякую за пораду!
Перегляну дану програму.
АЛЕ:
   Утиліта GBAK тим і відрізняється від інших засобів (упаковщиків архіваторів), що вона робить резервну копію бази у фоновому режимі. Навіть коли користувачі підключені до БД.  Але виявилося, що з файлу %backup%.fbk не можна відновити таблиці з товарами, накладними тощо.... на відміду від файла sklad.tcb.
   Тепер приходжу до висновку, що все ж таки треба було архівувати і файл sklad.tcb і відправляти на ftp-server а не тільки резервну копію. Правда доведеться перед цим перезавантажити сервер, щоб "відвалити всіх користувачів від бази"
   До речі... перевірив резервні копії інших клієнтів,- все піднімається!!!!! бази працюють!
   Якщо є ще пропозиції стосовно бекапів, і утіліт - пропонуйте. Не використовуйте хмари типу GoogleDrive!!!! Якщо згорів комп, чи щось подібне, - то це вас врятує! Якщо вірус-Шифрувальник то файли на хмарі теж будуть зашифровані! це перевіриний ФАКТ!
Теорія, - це однозначно треба, але на практиці, щось може бути не так! :-)

matiashi

Цитата: 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хв, все розвернулося на іншому компі. Для себе зробив висновок, що краще все використовувати в комплексі.
0674614593

majachok

Вітаю!
Окрім FTP ще існує SFTP!  :)

А стосовно зберігання, - то наче все було збережено... я теж думаф, що зараз за 15 хв розверну базу на іншому компі.... от саме база і не розвернулася (хоча логи по бекапу були нормальні).
Зробив висновок:
автоматизація - то тобре, але іноді теба з певною періодичністю перевіряти чи бекап можна підняти!!!
Теорія, - це однозначно треба, але на практиці, щось може бути не так! :-)

matiashi

Згодний, все потребує уваги.
0674614593