Доброго времени суток!
Oleg Matveyev wrote:
... уже 4.0 появится :)
Как? опять?
:-)
А что, мы до сих пор IB 4.0 используем :) - достаточно стабильная версия.
Всё хотим на FB 1.5.4 переползти, но это сопряжено с трудностями :(
Хоть клиентскую программу перевели c Delphi 1 на Delphi 3 - и
Здравствуйте, Дмитрий!
Dmitry Yemanov wrote:
Кузнецов Евгений wrote:
А в Firebird?
Тоже исправлена.
В 1.5.4 ее нет? Перерыл RN и tracker - нашел только, что она
правилась в 861 сборке Yaffil. Или это та, которую я приводил
выше?
Верно ли то, что select-запрос в CS, занимающийся сборкой
А что, мы до сих пор IB 4.0 используем :) - достаточно стабильная версия.
Всё хотим на FB 1.5.4 переползти, но это сопряжено с трудностями :(
Хоть клиентскую программу перевели c Delphi 1 на Delphi 3 - и то хорошо.
С ума сойти...
Ребята, а у Вас там какой год на дворе ? :)
Доброго времени суток!
PEAKTOP wrote:
С ума сойти...
Ребята, а у Вас там какой год на дворе ? :)
Delphi 3 вышла, если мне память не изменяет, в 1997,
IB 4.0 - в 1994 - так, что мы еще в XX веке живем :)
Новые проекты начинаем, конечно, на 1.5.4/2.0.1,
а старые перевести сложно, в том числе
Hello, Кузнецов!
You wrote on Sat, 07 Jul 2007 11:15:47 +0400:
КЕ А что, мы до сих пор IB 4.0 используем :) - достаточно стабильная
КЕ версия. Всё хотим на FB 1.5.4 переползти, но это сопряжено с
КЕ трудностями :( Хоть клиентскую программу перевели c Delphi 1 на Delphi
КЕ 3 - и то хорошо.
Доброго времени суток!
Vladimir A.Bakhvaloff wrote:
Ну, скажу просто, что с 4.2.1 на 1.5 перелезли на раз...
Поправил таблицы, в которых были поля DATE, TIME, TYPE и иже с ними... Ещё
какие-то мелочи...
Выдрали скрипт IBExpert'ом, создали из него базу на 1.5...
Перелили данные
Hello, Кузнецов!
You wrote on Sat, 07 Jul 2007 18:24:50 +0400:
?? Ну, скажу просто, что с 4.2.1 на 1.5 перелезли на раз...
?? Поправил таблицы, в которых были поля DATE, TIME, TYPE и иже с
?? ними... Ещё какие-то мелочи...Выдрали скрипт IBExpert'ом, создали
?? из него базу на
sasha ...
http://tracker.firebirdsql.org/browse/CORE-1349
--
Хорсун Влад
http://tracker.firebirdsql.org/browse/CORE-1349
Спасибо!
Доброго времени суток!
Horsun Vlad wrote:
http://tracker.firebirdsql.org/browse/CORE-1349
И от меня - спасибо.
Жаль только, за прогрессом не успеваю - когда мы свои БД
переведем под 2.1 - уже 4.0 появится :)
С уважением, Евгений.
Dmitri Kuzmenko [EMAIL PROTECTED] сообщил/сообщила в
новостях:
наоборот. это в IBExpert и т.п. надо сделать выключенным ключик
запретить сборку мусора. именно это и означает включение ключа -g.
Неет. Дружественное приложение должно по умолчанию вести себя так, как будет
правильно в
Hello, Igor!
Igor Zakhrebetkov wrote:
Долго думал, ничего не понял :)
Наверно, имелось в виду:
сделать выключенным ключик сборка мусора
или
сделать включённым ключик запретить сборку мусора
:)
да проще было посмотреть. при бэкапе в IBE
включена галка Garbage collection.
то есть, оно
Hello, Valery!
You wrote on Wed, 4 Jul 2007 15:19:30 +0400:
VG Кстати, да. Нелогично по умолчанию ставить опцию,
VG которой пользоваться НЕ НАДО.
VG Может, эта, инвертировать ключик -g в каком-нибудь
VG ближайшем релизе? ;-)
Та нi. Лучше RTFM (тебе и мне). Зачем несовместимость на пустом месте
Hello, Eugene!
You wrote on Tue, 03 Jul 2007 22:21:35 -0700:
EK Kochmin Alexandr wrote: а garbage collection?
EK Разумеется, backup делается с ключом -g
А нафига?
--
Удач
Alexander A. Venikov, Tobolsk, Russia
Hello, Alexander!
Alexander A. Venikov wrote:
EK Kochmin Alexandr wrote: а garbage collection?
EK Разумеется, backup делается с ключом -g
А нафига?
вот же, блин
с приложениями, которые нормально работают с транзакциями,
в базе мусор совершенно нормально кооперативно убирается и так.
Hello, Dmitri!
You wrote on Wed, 04 Jul 2007 11:37:59 +0400:
DK вот же, блин
DK Простая, элементарная логика. Или нет?
А, блин. Я делаю бэкап через сервисы (в IBExpert) с ВЫКЛЮЧЕННОЙ сборкой
мусора. Поэтому как-то считал, что -g ВКЛЮЧАЕТ сборку мусора при бэкапе.
Конечно же, нафиг
Alexander A. Venikov сообщил/сообщила в новостях следующее:
Поэтому как-то считал, что -g ВКЛЮЧАЕТ сборку мусора при бэкапе. Конечно
же, нафиг она не нужна.
Кстати, да. Нелогично по умолчанию ставить опцию, которой пользоваться НЕ
НАДО.
Может, эта, инвертировать ключик -g в каком-нибудь
Valery Gruzdev wrote:
Поэтому как-то считал, что -g ВКЛЮЧАЕТ сборку мусора при бэкапе.
Конечно же, нафиг она не нужна.
Кстати, да. Нелогично по умолчанию ставить опцию, которой пользоваться
НЕ НАДО.
Может, эта, инвертировать ключик -g в каком-нибудь ближайшем релизе? ;-)
Я вам
On Wed, 04 Jul 2007 15:19:30 +0400, Valery Gruzdev [EMAIL PROTECTED] wrote:
Может, эта, инвертировать ключик -g в каком-нибудь ближайшем релизе?
Нет уж. Бэкапом IBExper'а никогда не пользовались, и инвертировать в голове
ничего не надо. И скриптов написано...
Только для тебя отдельный билд,
Hello, Valery!
Valery Gruzdev wrote:
Кстати, да. Нелогично по умолчанию ставить опцию, которой пользоваться
НЕ НАДО.
Может, эта, инвертировать ключик -g в каком-нибудь ближайшем релизе? ;-)
наоборот. это в IBExpert и т.п. надо сделать выключенным ключик
запретить сборку мусора. именно это
Hello, Eugene!
Eugene Kuznetsov wrote:
Я не знаю как можно получить кривую БД после рестора (на нормально
работающем компьютере)
Я имею в виду текущий случай, когда gbak по какой-то причине не
написал в лог об ошибке.
бывает и другое.
www.ibase.ru/devinfo/db_repair.htm
Мыть руки
Dmitri Kuzmenko ...
собственно, я впервые слышу чтобы gbak вел себя так.
Я тоже. В прочем проблема не в gbak'е, а в fbclient'е.
Я думаю мы это всё-таки исправим, учитывая распространённость
ИБЕ и прочих чересчур умных утилит и их популярность в среде тех,
кто принципиально не умеет
Кузнецов Евгений ...
Доброго времени суток!
Vlad Horsun wrote:
Бекап через сервисы честно ругается :
message length error (encountered 5742, expected 5738)
А вот gbak почему-то глотает эту ошибку, или она до него не доходит...
Т.к. есть нюансы вносимые сетевым уровнем. Вопрос
Здравствуйте, Дмитрий!
Dmitri Kuzmenko wrote:
бывает и другое.
www.ibase.ru/devinfo/db_repair.htm
Кстати, по поводу этого документа
Остановка во время сборки мусора
...
В Yaffil эта проблема исправлена.
А в Firebird? Смотрел в RN, нашел только
Not registered
fixed by V. Horsun
(1.5.2)
Доброго времени суток!
Vlad Horsun wrote:
Сетевой протокол не передаёт длину буфера...
Спасибо за информацию.
Независимо от данного вопроса - бекап намного быстрее выполняется
через сервисы.
Правильно ли я понимаю, что на CS (1.5.4/2.0.1) gbak -se может быть
остановлен снятием
Кузнецов Евгений пишет:
и это
безопасная операция, поскольку gbak выполняется в читающей транзакции?
а garbage collection?
--
Кочмин Александр
Hello, Евгений!
Кузнецов Евгений wrote:
Согласен, и стараюсь этого избегать (хотя в IB 4.0 не получается).
Но, если ошибка возможна, то рано или поздно ее сделают.
сервер сам тоже модифицирует системные таблицы. но он делает
это правильно, а не как попало.
--
Dmitri Kouzmenko,
Hello, Alexandr!
Kochmin Alexandr wrote:
и это
безопасная операция, поскольку gbak выполняется в читающей транзакции?
а garbage collection?
кому нынче нужен gc при бэкапе???
--
Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Кузнецов Евгений wrote:
А в Firebird?
Тоже исправлена.
--
Дмитрий Еманов
Доброго времени суток!
Kochmin Alexandr wrote:
а garbage collection?
Разумеется, backup делается с ключом -g
Хотя сам вопрос интересен - я неоднократно убивал select-запросы на CS
и ни разу не сталкивался ни с повреждением БД, ни даже с orphan pages.
Это везение или кооперативная сборка мусора
Здравствуйте, Дмитрий!
Dmitri Kuzmenko wrote:
сервер сам тоже модифицирует системные таблицы. но он делает
это правильно, а не как попало.
Нет, я имел в виду именно прямую правку системных таблиц - раз она
таки возможна, то я или остальные разработчики с недосыпу могут это
сделать.
С
Доброго времени суток!
Vlad Horsun wrote:
gfix ловит только физические ошибки (да и то не все, увы).
Интересно. Таким образом, успешные gfix -v -full и backup-restore не
являются гарантией целостности БД?
Существует ли вообще набор действий, позволяющих это однозначно
установить?
С уважением,
Eugene Kuznetsov ...
Доброго времени суток!
Vlad Horsun wrote:
gfix ловит только физические ошибки (да и то не все, увы).
Интересно. Таким образом, успешные gfix -v -full и backup-restore не
являются гарантией целостности БД?
gfix - не является гарантией, это открытие ?
Я не
Контрольный рестор в голову тебе поможет.
Нихрена он не поможет. Я заметил только потому что у меня на таблицу ВК
были и рестор обломался на их активации и что-то там в конце написал. А
если бы небыло ВК, то всё бы прекрасно отресторилось.
Eugene Kuznetsov пишет:
Я не знаю как можно получить кривую БД после рестора (на нормально
работающем компьютере)
Я имею в виду текущий случай, когда gbak по какой-то причине не
написал в лог об ошибке.
Мыть руки перед и во время работы
Это профилактика, а методы диагностики
Я с Хвастуновым общался на предмет использования ALTER DOMAIN вместо
того что щас и он вроде бы согласился, но есть проблемки.
Я попытался эту команду использовать и уж сильно она убогой оказалась.
Например если я использую домен в ПК и попытаюсь поменять тип домена, то
она меня даже когда
sasha wrote:
Какие-то улучшения по этому поводу планируются?
Допускаются лишь совместимые (по типу данных) изменения, остальное в сад.
--
Дмитрий Еманов
Допускаются лишь совместимые (по типу данных) изменения, остальное в сад.
Два примера:
1) Создал домен: CREATE DOMAIN Key AS INT;
и таблицу с ПК типа этого домена: CREATE TABLE TAB (ID Key PRIMARY KEY);
Данные в таблицу не вставлял!!!
Пишу: ALTER DOMAIN Key TYPE BIGINT;
получаю:
MODIFY
sasha wrote:
1) Создал домен: CREATE DOMAIN Key AS INT;
и таблицу с ПК типа этого домена: CREATE TABLE TAB (ID Key PRIMARY KEY);
Данные в таблицу не вставлял!!!
Пофиг, DDL никогда не смотрит на данные.
Пишу: ALTER DOMAIN Key TYPE BIGINT;
получаю:
MODIFY RDB$FIELDS failed.
action
Dmitry Yemanov wrote:
ЗЫ. Радуйся, что хоть так, а то стандарт даже увеличивать поля не дает.
Злой ты. Ему ж придётся таки начать чутка думать, перед тем как
кодить. А это мешает работе.
--
Regards. Ded.
Доброго времени суток!
Vlad Horsun wrote:
Бекап через сервисы честно ругается :
message length error (encountered 5742, expected 5738)
А вот gbak почему-то глотает эту ошибку, или она до него не доходит...
Т.к. есть нюансы вносимые сетевым уровнем. Вопрос (для меня)
закрыт ;)
Можно ли
Патамучта так сделано. Специально. Нефиг шерстить все записи всех таблиц
ради твоего хотения.
Так я ж не потому спрашиваю что оно мне надо, а ради того чтобы узнать
как лучше в эксперте это сделать.
Как такое получилось ? Это я у тебя хочу спросить :)
Я извиняюсь что подкинул тебе работу...
Похоже действительно поле было TIMESTAMP и я его изменил на DATE.
Только что попробовал такое сделать в эксперте и он на изменение генерит
такую вот команду:
update RDB$FIELDS set RDB$FIELD_TYPE =
sasha ...
Как такое получилось ? Это я у тебя хочу спросить :)
Я извиняюсь что подкинул тебе работу...
Похоже действительно поле было TIMESTAMP и я его изменил на DATE.
В таблице 13 форматов, начиная с 11-го в этом поле тип изменён на DATE
Только что попробовал такое сделать в
А он правильно работает, чего его трогать ?
Ну чтобы или ошибку кидало, или таки бэкапило данные. А представь если
бы у меня ключей небыло? Пропали бы данные из таблицы и никто бы не
заметил :-(
Да, к стати, а gfix не должен ли такое выявлять?
sasha ...
А он правильно работает, чего его трогать ?
Ну чтобы или ошибку кидало, или таки бэкапило данные. А представь если
бы у меня ключей небыло? Пропали бы данные из таблицы и никто бы не
заметил :-(
Ибо нефиг в системных таблицах грязными руками лазить.
Причём тут gbak ?
--
sasha ...
Да, к стати, а gfix не должен ли такое выявлять?
Нет. gfix ловит только физические ошибки (да и то не все, увы).
--
Хорсун Влад
sasha ...
Чё делать?
А то ты не знаешь, куа слать :) Большоё оно ?
--
Хорсун Влад
А то ты не знаешь, куа слать :) Большоё оно ?
Вы там все не на разных частях сервера специализируетесь разве?
Оно крохотное. Это база для разработки. Всего 2.3 метра в архиве. Шлю
тебе на users.sourceforge.net ...
Не получается на саурсфорж - говорит большой файл очень... Куда ещё
можно попробовать?
sasha wrote:
Куда ещё можно попробовать?
Тебя на рапидшаре забанили? :-)
Шли мне, хотя бы.
--
Дмитрий Еманов
Dmitry Yemanov ...
sasha wrote:
Куда ещё можно попробовать?
Тебя на рапидшаре забанили? :-)
Шли мне, хотя бы.
Я получил и уже весь вечер смотрю, там хрень какая-то.
Debug-build даёт ошибку, а release почему-то нет...
--
Хорсун Влад
Vlad Horsun ...
Я получил и уже весь вечер смотрю, там хрень какая-то.
Debug-build даёт ошибку, а release почему-то нет...
Поле AccountExpirationDate имеет домен RDB$1627, который
есть тип 12 (sql_date), но в RDB$FIELD_LENGTH записано 8, а не 4.
Бекап через сервисы честно ругается :
Vlad Horsun ...
Vlad Horsun ...
Я получил и уже весь вечер смотрю, там хрень какая-то.
Debug-build даёт ошибку, а release почему-то нет...
Поле AccountExpirationDate имеет домен RDB$1627, который
есть тип 12 (sql_date), но в RDB$FIELD_LENGTH записано 8, а не 4.
Апдейтишь
Vlad Horsun wrote:
Поле AccountExpirationDate имеет домен RDB$1627, который
есть тип 12 (sql_date), но в RDB$FIELD_LENGTH записано 8, а не 4.
Был ранее таймштампом?
--
Дмитрий Еманов
56 matches
Mail list logo
