|
|
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
весьма своеобразная ошибка вылезла у кого-то gbak: ERROR:violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_12" on table "RDB$RELATION_CONSTRAINTS" gbak: ERROR: Problematic key value is ("RDB$CONSTRAINT_NAME" = 'RDB$INDEX_0') По идее, при несовпадении версий, утилиты должны или чётко на это ругаться с самого начала, или таки отрабатывать. К сожалению, подробностей что именно делали, пока нет https://stackoverflow.com/questions/54634673/gbak-restoring-db-raises-violation-of-primary-or-unique-key-constraint ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2019, 14:02 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Arioch, Ага! - сказали суровые сибирские лесорубы. (с))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.02.2019, 15:06 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Дополнительная инфа I ran gbak -B from fb 2.5 client environment and ran gbak -C/-R on FB 3.0 server. Without -T option at backup. Without -se but I specified target server as localhost:/xxx. ....Without -T option... В общем, с одной стороны - про сибирских лесорубов в тему. С другой - всё равно это как-то неправильно. Если информация в принципе несовместима с текущей версией бэкапа - он просто не должен даже пытаться. В конце концов это просто ещё один случай "невосстановимого бэкапа" - довольно подлой своей до поры невидимостью проблемы ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2019, 18:37 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Arioch, эта чушь не имеет никакого отношения к исходной ошибке. Хватит искать "проблему" там, где ей и не пахнет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2019, 19:18 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Arioch, когда вы уже выучите, что опция -T - это transportable, которая ВКЛЮЧЕНА ПО УМОЛЧАНИЮ, и которая имеет отношение к разному порядку байт в целых числах на разных платформах (big/little endian). НЕ по умолчанию - опция -NT, non-transportable. -t - это, видимо, какой-то атавизм, который существовал во времена, когда дефолтный бэкап был НЕтранспортабельным. Доказательство дефолтности -t: 1. запускаем gbak -? видим, что опция transportable - это "data in XDR format" 2. делаем бэкап БЕЗ опций -t или -nt 3. делаем рестор с записью лога в файл 4. смотрим файл рестора, там вначале написано gbak:transportable backup -- data in XDR format p.s. один чушь напишет (про -t), а другой повторяет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2019, 19:39 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Arioch, 5. если сделать бэкап с -nt, а потом рестор, то в начале лога рестора ничего про XDR не будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2019, 19:41 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
hvlad, скажи что имеет и где пахнет ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2019, 16:10 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Ariochпри несовпадении версий, утилиты должны или чётко на это ругаться с самого начала, или таки отрабатывать. - чушь номер раз С чего ты взял, что это не так ? AriochЕсли информация в принципе несовместима с текущей версией бэкапа - он просто не должен даже пытаться. - чушь номер два Перед тем как узнать, что что-то где-то с чем-то несовместимо (а это совершенно не имеет никакого отношения к данному случаю) - нужно как раз попытаться AriochВ конце концов это просто ещё один случай "невосстановимого бэкапа" - чушь номер три Ты понятия не имеешь что там было у юзера на самом деле и из-за чего его попустило. Но уже утверждаешь про "ещё один случай" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2019, 17:27 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
hvlad, чтобы узнать о несовместимости нужно попытаться? серьёзно? это критерий совместимости по-фаербёрдски? > ERROR:violation of PRIMARY or UNIQUE KEY constraint "RDB$INDEX_12" on table "RDB$RELATION_CONSTRAINTS Одно из двух: ...либо в FBK файле было два индекса с одинаковым именем ...либо не было Тогда: ...либо утилитой GBAK был создан некорректный FBK-файл ...либо утилита GBAK некорректно обработала корректный FBK-файл > Ты понятия не имеешь что там было у юзера на самом деле Ну да, наверное у него была самописка на базе FB с непубличными модификациями исходников. Мало ли чего не бывает > про "ещё один случай" FBK создался? да. Восстановился? нет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2019, 17:50 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Ariochнаверное у него была самописка на базе FB с непубличными модификациями исходников Вот сейчас как раз тот случай, когда полезно запустить backup под отладчиком... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2019, 18:12 |
|
||
|
gbak 2.5 vs server 3.0.4
|
|||
|---|---|---|---|
|
#18+
Ariochчтобы узнать о несовместимости нужно попытаться? серьёзно? это критерий совместимости по-фаербёрдски? Ты дурак ? Или идиот ? Да я - я уже не стесняюсь в выражениях, ибо это перешло все границы допустимого. Вот тебе файл - скажи мне, не открывая его: что там внутри и с чем оно совместимо ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2019, 18:16 |
|
||
|
|
start [/forum/topic.php?fid=40&msg=39774009&tid=1560803]: |
0ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
2ms |
check topic access: |
2ms |
track hit: |
363ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
1ms |
| others: | 330ms |
| total: | 786ms |
| 0 / 0 |
