Баз у нас море. Среди них есть важные: собственная бухгалтерия,
разработка по и т.п. Настроено автоматическое архивирование. Которое
собственно работает как часы. Недавно понадобилось восстановить одну
базу. Залез в архив, а она не разбэкапливается... Начал проверять:
просто звиздец, ничего не разб
Hello, Andrei!
Andrei wrote:
Предложение: чтобы избежать такой ситуации, gbak видя что версия
структуры БД отличается от ФБ 2.5
должен перед архивированием проверить BLR хранимых процедур и
триггеров. И если на этом этапе будут ошибки, то не делать архив
вообще.
blr при бэкапе не проверяется
"Andrei" ...
Баз у нас море.
А вменяемого админа видимо нет, судя по ниже написанному и ранее
озвученному. Вывод :
Среди них есть важные: собственная бухгалтерия,
разработка по и т.п.
вы их оцениваете в 0 целых 0 десятых. В любой валюте.
Настроено автоматическое архивирование. Кото
Баз у нас море. Среди них есть важные: собственная бухгалтерия,
разработка по и т.п. Настроено автоматическое архивирование. Которое
собственно работает как часы. Недавно понадобилось восстановить одну
базу. Залез в архив, а она не разбэкапливается... Начал проверять:
просто звиздец, ничего не р
> вы их оцениваете в 0 целых 0 десятых. В любой валюте.
почему? ценим. поэтому и RAID и автоматическое архивирование
>
> А чего вообще пути ФБ\дятла в PATH делают ?
для доступа к утилитам командной строки: gbak, isql...
> Дааа ??? Даже когда сервер - дятел ??? Не ресторит ??? Ай-яй-
On Apr 15, 10:20 pm, "Vlad Khorsun" wrote:
> "Andrei" ...
> > что в какой-то момент
> > в путях каталог BIN сервера 2.5 стал впереди Яфиловского.
> А чего вообще пути ФБ\дятла в PATH делают ?
Во-во, я тут пришел к выводу, что содержимое PATH надо минимизировать
во избежание таких вот пробле
"AndreiK" ...
вы их оцениваете в 0 целых 0 десятых. В любой валюте.
почему?
По факту
А чего вообще пути ФБ\дятла в PATH делают ?
для доступа к утилитам командной строки: gbak, isql...
Детсад, ей-ей. Другую причину придумать можешь ?
Дааа ??? Даже когда сервер - дятел ??? Не рес
>
> > для доступа к утилитам командной строки: gbak, isql...
>
> Детсад, ей-ей. Другую причину придумать можешь ?
т.е. предлагаете всегда вызывать утилиту так:
c:\program files\firebird\firebird_2_5\bin\gbak
и в самом деле. нафига этот path придумали.
>
> >> Дааа ??? Даже когда сервер - д
"AndreiK" ...
> для доступа к утилитам командной строки: gbak, isql...
Детсад, ей-ей. Другую причину придумать можешь ?
т.е. предлагаете всегда вызывать утилиту так:
c:\program files\firebird\firebird_2_5\bin\gbak
Да, а что ? Пальчики жалко ? Не ставь в путь "program files" :-D
и
Andrei wrote:
Предложение: чтобы избежать такой ситуации, gbak видя что версия
структуры БД отличается от ФБ 2.5
должен перед архивированием проверить BLR хранимых процедур и
триггеров. И если на этом этапе будут ошибки, то не делать архив
вообще.
Версия базы яффила не отличается от версии ба
Hello, AndreiK!
AndreiK wrote:
т.е. предлагаете всегда вызывать утилиту так:
c:\program files\firebird\firebird_2_5\bin\gbak
и в самом деле. нафига этот path придумали.
нафига вообще ставить ФБ в Program files, тем более с таким
идиотским путем. Как будто еще могут быть
c:\program files\fi
Ща буду грязно ругаться.
Влад, береги нервы. А то на меня совсем ничего не останетсо :-(
Коваленко Дмитрий.
и в самом деле. нафига этот path придумали.
Я как-то просек фишку "нафига". Что нехило пои..тсо при написании своего
запускателя процессов.
нафига вообще ставить ФБ в Program files,
А я щас задам более суровый вопрос - а нафига его вообще ставить?
Коваленко Дмитрий.
Здравствуйте, AndreiK.
Вы писали 16 апреля 2009 г., 5:10:29:
> т.е. предлагаете всегда вызывать утилиту так:
> c:\program files\firebird\firebird_2_5\bin\gbak
>8<-
rem настройки изменяемые
set USER=SYSDBA
set PASSWD=password
set gbak_exe=c:\program files\fir
14 matches
Mail list logo
