Доброго времени суток!
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 и т.п. надо сделать выключенным ключик
запретить сборку мусора. именно это
Dmitri Kuzmenko пишет:
наоборот. это в IBExpert и т.п. надо сделать выключенным ключик
запретить сборку мусора. именно это и означает включение ключа -g.
Долго думал, ничего не понял :)
Наверно, имелось в виду:
сделать выключенным ключик сборка мусора
или
сделать включённым ключик
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 почему-то глотает эту ошибку, или она до него не доходит...
Т.к. есть нюансы вносимые сетевым уровнем. Вопрос
Я думаю мы это всё-таки исправим, учитывая распространённость
ох, чую - пахнет дело новыми запретами :-)
Oleg Matveyev wrote:
Я думаю мы это всё-таки исправим, учитывая распространённость
ох, чую - пахнет дело новыми запретами :-)
Точна! Запретить gbak к едреням и вся нЕдолга! :-D
--
Regards. Ded.
Здравствуйте, Дмитрий!
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.
Был ранее таймштампом?
--
Дмитрий Еманов
WildSery wrote:
Чего-то я тебя недопонял. Могу я писать sum() в WHERE. Оптимизатор смущает
только домножение на d.dnum8 внутри sum().
Если его убрать - то ошибки нет.
Я думаю, его сбивает с толку совпадение выражений в Select и в Where
хотя в основном запросе я что-то не вижу GROUP BY
On Mon, 25 Jun 2007 17:50:52 +0400, Konstantin R. Beliaev [EMAIL PROTECTED]
wrote:
Я думаю, его сбивает с толку совпадение выражений в Select и в Where
хотя в основном запросе я что-то не вижу GROUP BY
Уже обсудили, вроде.
Дело вовсе не в выражении в селекте - его можно убрать, результат не
On Fri, 22 Jun 2007 07:17:05 +0400, Alexander A. Venikov [EMAIL PROTECTED]
wrote:
DY Я уже объяснял, что весь подзапрос считается агрегатом.
DY Ведь select sum() писать можно, а where sum() - нельзя.
Для этого having есть.
Точно подмечено.
Вот только группировки во внешнем запросе нет, и
Ded пишет:
WildSery wrote:
Вроде ничего чуднОго. Найти документы у которых сумма не равна сумме
по строкам с учётом, что курс в заголовке.
Обойти конечно не сложно, но всё же.
Может, я мыслю как-то уж очень вычурно, как бы ты такой запрос выполнил?
(просто по логике задачи если мыслить,
On Thu, 21 Jun 2007 00:13:28 +0400, Ded [EMAIL PROTECTED] wrote:
? Или я тож к вечеру того... вычурно... :)
Ещё до писанины сюда сделал с GROUP BY, оптимизатор же сам подсказывает, как он
хочет :)
Но я всё же думаю, что это обходной путь, а не логичное решение. Дополнительная
сортировка -
Oleg LOA wrote:
У него агрегат не по d, по l
Сервер считает по-другому. Причем не только наш, но и SQL2005, например :-)
--
Дмитрий Еманов
á MySQL - ÐÏ ÔÒÅÔØÅÍÕ :) éÎÔÅÒÅÓÎÏ, ÞÔÏ ÓÔÁÎÄÁÒÔ ÇÏ×ÏÒÉÔ ÎÁ ÜÔÕ ÔÅÍÕ.
Regards,
Aleksey Karyakin
Dmitry Yemanov [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
Oleg LOA wrote:
õ ÎÅÇÏ ÁÇÒÅÇÁÔ ÎÅ ÐÏ d, ÐÏ l
óÅÒ×ÅÒ ÓÞÉÔÁÅÔ ÐÏ-ÄÒÕÇÏÍÕ. ðÒÉÞÅÍ ÎÅ ÔÏÌØËÏ ÎÁÛ, ÎÏ É SQL2005, ÎÁÐÒÉÍÅÒ
Oleg LOA [EMAIL PROTECTED] wrote in message
news:[EMAIL PROTECTED]
Aleksey Karyakin [EMAIL PROTECTED] wrote
in message news:[EMAIL PROTECTED]
á MySQL - ÐÏ ÔÒÅÔØÅÍÕ :) éÎÔÅÒÅÓÎÏ, ÞÔÏ ÓÔÁÎÄÁÒÔ ÇÏ×ÏÒÉÔ ÎÁ ÜÔÕ ÔÅÍÕ.
ñ ÎÅ ÚÎÁÀ ÞÔÏ ÇÏ×ÏÒÉÔ ÓÔÁÎÄÁÒÔ, ÎÏ ×ÙÞÉÓÌÉÔØ ÜÔÉ ÚÎÁÞÅÎÉÑ ÎÉÞÔÏ ÎÅ ÍÅÛÁÅÔ.
Aleksey Karyakin пишет:
А MySQL - по третьему :) Интересно, что стандарт говорит на эту тему.
Я не знаю что говорит стандарт, но вычислить эти значения ничто не мешает.
Там нет условия на агрегат о основной таблице.
По разному можно вычислять. Сколько рядов будет в результате:
select
Aleksey Karyakin wrote:
А MySQL - по третьему :)
У PGSQL тоже есть отличие в одном из случаев.
Интересно, что стандарт говорит на эту тему.
Арно в свое время продрался через дебри стандарта, в результате мы имеем
сабжевый вопрос :-) Повторить его подвиг я не рискну :-)
--
Дмитрий
WildSery wrote:
Тогда почему сервер так считает только для WHERE, а в подзапросе нормально?
Я уже объяснял, что весь подзапрос считается агрегатом. Ведь select
sum() писать можно, а where sum() - нельзя.
Детальный разбор полетов - в fb-devel.
--
Дмитрий Еманов
Oleg LOA wrote:
with
t1 as (select 1 f1,1 f2 from dual union all select 1 f1,1 f2 from dual union all select 1 f1,1 f2 from dual),
t2 as (select 1 f1,1 f2 from dual union all select 1 f1,1 f2 from dual)
select (select sum(t1.f1) from t2) from t1
А вот так:
select (select sum(t1.f1) from t2
Andrei Yeryomin wrote:
По-моему это маразм.
Не буду спорить :-)
select (select sum(t1.link) from t2) from t1 =
Или это альтернативная запись вот этого:
select sum(t1.link) from t1
Именно, как бы не было это смешно.
--
Дмитрий Еманов
äÁ, ËÒÕÔÁÑ ÆÉÛËÁ.
SQL2003 draft: (section 6.9)
The aggregation query is the innermost qualifying query, for the columns
referenced in the
aggregate function.
Regards,
Aleksey Karyakin
Dmitry Yemanov [EMAIL PROTECTED] wrote in
message news:[EMAIL PROTECTED]
Aleksey Karyakin wrote:
á
Dmitry Yemanov пишет:
Andrei Yeryomin wrote:
По-моему это маразм.
Не буду спорить :-)
select (select sum(t1.link) from t2) from t1 =
Или это альтернативная запись вот этого:
select sum(t1.link) from t1
Именно, как бы не было это смешно.
t1
link val
1 1
2 1
3 1
t2
link val
1 1
2 1
Dmitry Yemanov пишет:
Oleg LOA wrote:
with t1 as (select 1 f1,1 f2 from dual union all select 1 f1,1 f2 from
dual union all select 1 f1,1 f2 from dual),
t2 as (select 1 f1,1 f2 from dual union all select 1 f1,1 f2 from dual)
select (select sum(t1.f1) from t2) from t1
А вот так:
select
Hello, Dmitry!
You wrote on Thu, 21 Jun 2007 16:48:06 +0400:
W Тогда почему сервер так считает только для WHERE, а в
W подзапросе нормально?
DY Я уже объяснял, что весь подзапрос считается агрегатом.
DY Ведь select sum() писать можно, а where sum() - нельзя.
Для этого having есть.
--
Удач
Alexander A. Venikov wrote:
Для этого having есть.
Об этом сервер ему и говорил.
--
Дмитрий Еманов
Вот такой запрос:
select did, (select sum(l.enum5*d.dnum8) from lin l where d.did = l.eiddoc)
from doc d
where d.dnum5 != (select sum(l.enum5*d.dnum8) from lin l where d.did =
l.eiddoc)
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Cannot use an aggregate function in a WHERE
WildSery wrote:
select did, (select sum(l.enum5*d.dnum8) from lin l where d.did = l.eiddoc)
from doc d
where d.dnum5 != (select sum(l.enum5*d.dnum8) from lin l where d.did =
l.eiddoc)
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Cannot use an aggregate function in a WHERE
WildSery wrote:
Недоработка?
Сложно сказать. Запрос уж больно чудной.
В поздапросе его пропускает (и правильно). В WHERE что ли по-другому проверка
идёт?
Дык подзапрос тут считается агрегатом, потому и пропускается. Напрямую
же sum() ты в WHERE писать не можешь, вот и тут аналогично.
WildSery wrote:
Может, я мыслю как-то уж очень вычурно, как бы ты такой запрос выполнил?
Дело не во мне, а в сервере. Ссылка на внешнее поле внутри агрегата
вводит его в ступор :-)
Чего-то я тебя недопонял. Могу я писать sum() в WHERE.
Не для агрегируемой таблицы:
select sum(T.field)
WildSery wrote:
Вроде ничего чуднОго. Найти документы у которых сумма не равна сумме по строкам
с учётом, что курс в заголовке.
Обойти конечно не сложно, но всё же.
Может, я мыслю как-то уж очень вычурно, как бы ты такой запрос выполнил?
(просто по логике задачи если мыслить, обходные пути я
Hello, WildSery!
WildSery wrote:
Теперь тестирую сборку мусора (прибил эти 10 млн. записей).
gfix -sweep
1.0.3 - 213 с
2.0.1 - 235 с (-10%)
Сборка мусора меня несколько озадачила. В каких условиях она будет (как обещали гораздо)
быстрее чем единица?
в 2.0 есть 3 варианта сборки мусора.
Dmitri Kuzmenko ...
Hello, WildSery!
WildSery wrote:
Теперь тестирую сборку мусора (прибил эти 10 млн. записей).
gfix -sweep
1.0.3 - 213 с
2.0.1 - 235 с (-10%)
Сборка мусора меня несколько озадачила. В каких условиях она будет (как
обещали гораздо)
быстрее чем единица?
В
On Wed, 11 Apr 2007 10:58:02 +0400, Dmitri Kuzmenko [EMAIL PROTECTED] wrote:
в 2.0 есть 3 варианта сборки мусора.
У меня классик, потому только один.
Кроме того, ты по этой мусорной
таблице построй неуникальный индекс, а потом попробуй gfix -sweep
запустить. На 10млн записей и FB 1.0 ты
Vlad Horsun [EMAIL PROTECTED] wrote in message news:[EMAIL PROTECTED]
Угу. Особенно на windows
А шо на линух код другой в сборщике?
On Wed, 11 Apr 2007 17:01:26 +0400, WildSery wildsery-JGs/[EMAIL PROTECTED]
wrote:
потом, во всех версиях Superserver IB/FB (кроме 2.01, если Влад меня не
поправит)есть такая фигня, что при постоянных обновлениях одних и тех же
данных фоновая сборка мусора оставляет часть мусора на диске.
Oleg LOA ...
Vlad Horsun ...
Угу. Особенно на windows
А шо на линух код другой в сборщике?
Там THREAD_YIELD другой. В винде со sleep(1) сборщик просто ничего
не делал, а со sleep(0) стал молотить, как и должен был. Про линукс я такого
не слыхивал
--
Хорсун Влад
Сразу говорю - условия весьма специфические, однако какая-то странная картина
нарисовалась.
Тесты проводились на ASP Linux Server 4, машинка довольно дохлая, диск один.
Сначала один сервер, затем переустановка, другой. Конфиги по дефолту.
База наша рабочая, только справочники и конфигурация,
Hello, Dmitry!
You wrote on Fri, 30 Mar 2007 12:20:39 -0700:
KD Пятница на форуме какая-та мертвая. Все похавались, что ли?
Это как? Самосъелись?
Удач
--
Alexander A. Venikov, Tobolsk, Russia
Real e-mail address is venixangry_dogtndottobdotru
Пятница на форуме какая-та мертвая. Все похавались, что ли?
CS FB 2.0.1 for Win (релиз)
Выловил такую проблему. При бакапе через gbak.exe с ключиком SE (то
есть через сервисы), в случае ошибки gbak.exe возвращает код ноль -
типа ошибок нет.
В моем случае засада была в отсутствии у сервера прав
WildSery wrote:
Блин. Посмотрел ещё раз - эксепшн оказывается из-за 3-го диалекта :)
Мать... Хоть бы пожалели тех, кто еще с 4.0 с вами...
Или подобное
select substring(cast(current_timestamp as varchar(24)) from 1 for 19)
from rdb$database
Привет, Alex!
Вы пишешь 01 марта 2007:
AB Или подобное
AB select substring(cast(current_timestamp as varchar(24)) from 1 for 19)
AB from rdb$database
SubString тут излишен ;о)
--
With best regards, Alex Cherednichenko.
On Thu, 01 Mar 2007 13:02:02 +0300, Alex Bekhtin [EMAIL PROTECTED] wrote:
Или подобное
select substring(cast(current_timestamp as varchar(24)) from 1 for 19)
from rdb$database
Не хочу закладывать грабли с 1-MAR-2007 против 2007-03-01.
--
Сергей Смирнов.
On Thu, 01 Mar 2007 13:07:48 +0300, Alex Cherednichenko [EMAIL PROTECTED]
wrote:
AB Или подобное
AB select substring(cast(current_timestamp as varchar(24)) from 1 for 19)
AB from rdb$database
SubString тут излишен ;о)
Без сабстринга почему-то на виндовом 2.0.1 пишет Arithmetic overflow
Привет, WildSery!
Вы пишешь 01 марта 2007:
AB select substring(cast(current_timestamp as varchar(24)) from 1 for 19)
AB from rdb$database
SubString тут излишен ;о)
W Без сабстринга почему-то на виндовом 2.0.1 пишет Arithmetic overflow ...
W На линухе нормально. К чему бы?
WildSery wrote:
На виндовом Arithmetic overflow ...
На линухе нормально. К чему бы?
А патамушта нехрен :-D
--
Regards. Ded.
Hello, WildSery!
You wrote on Thu, 01 Mar 2007 17:01:15 +0300:
AB select substring(cast(current_timestamp as varchar(24)) from 1 for
AB 19) from rdb$database
?? SubString ÔÕÔ ÉÚÌÉÛÅÎ ;Ï)
W âÅÚ ÓÁÂÓÔÒÉÎÇÁ ÐÏÞÅÍÕ-ÔÏ ÎÁ ×ÉÎÄÏ×ÏÍ 2.0.1 ÐÉÛÅÔ Arithmetic overflow
W ... îÁ ÌÉÎÕÈÅ ÎÏÒÍÁÌØÎÏ. ë
Привет, Vladimir!
Вы пишешь к WildSery 01 марта 2007:
VA У меня на 12810 select cast(current_timestamp as varchar(24)) from
VA rdb$database отработало на раз...
Дык речь об менее чем 24.
--
With best regards, Alex Cherednichenko.
Результаты 1 - 100 из 106 matches
Mail list logo