Re: Запрос в FB2.5 выполняется дольше чем в FB2.0

2012-05-08 Пенетрантность Ice_Harley

>
> Все, hvlad помог разобраться в чем дело.

 OBJECT - текстовое поле, а сравнивается с числом. Видимо такие неявные 
преобразования в 2.0 были реализованы иначе чем в 2.5


Re: Trigger

2012-03-11 Пенетрантность NikolayV81
Так должно быть по логике, вставка в таблицу мастер только после
успешного выполнения триггеров, пока они не завершены, данные старые.

On Mar 11, 6:05 pm, "Dmitry Lendel"  wrote:
> .
> Master Details
>
>
>   new.masterfield=9
>   update Details set Somefiled = Value where ...
>
>
> Select masterfield from Master where ...
>
> , . . .
> . ?
> 2.1.4
>
>

Re: Упала база, упала на пол...

2012-03-07 Пенетрантность Dmitry Yemanov

07.03.2012 9:11, Dumitru Condrea пишет:


Что делать? Куда "копать"?


Активизировать индексы в правильном порядке.


--
Дмитрий Еманов




Re: Упала база, упала на пол...

2012-03-07 Пенетрантность Ovchinnikov Vasily

Alex Cherednichenko пишет:

Hello, Dumitru Condrea!
You wrote on Tue, 6 Mar 2012 21:11:32 -0800 (PST)


при активации одного из индекса выдаёт ошибку:

Unsuccessful execution caused by system error that precludes
successful execution of subsequent statements.
internal gds software consistency check (partner index description not
found (175))

Что делать? Куда "копать"?



http://www.ibase.ru/devinfo/errors.htm
Сразу первое же из того, что там написано.


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Упала база, упала на пол...

2012-03-06 Пенетрантность Alex Cherednichenko
Hello, Dumitru Condrea!
You wrote on Tue, 6 Mar 2012 21:11:32 -0800 (PST)

> при активации одного из индекса выдаёт ошибку:
> 
> Unsuccessful execution caused by system error that precludes
> successful execution of subsequent statements.
> internal gds software consistency check (partner index description not
> found (175))
> 
> Что делать? Куда "копать"?

Форин кей?
И нет ему "партнёра"...



Re[2]: Различия версий снапшотов

2012-03-05 Пенетрантность Sergey Mereutsa
Привет!

Да, правильно Еманов говорит: "Никто README не читает". Он ещё при
этом материся, наверняка.

http://www.dqteam.com/fb2/README.TXT - сто лет там лежит.

Что мне в about написать? Что это мои сборки и используете на свой
страх и риск?
По-моему это и так очевидно. Они собираются из публичных сорцов
примерно раз в неделю или по просьбе тех, кому надо срочно.
Ничем от обычных снапшотов не отличаются - разве что делаются реже.
Я сам эти билды использую переодически - всплывающие проблемы
рапортуются птицеводам.

P.S. Специально для ворчунов - напишу, что мои сборки ничем от обычных
не отличаются.

-- 
Best regards,
 Sergeymailto:gebele...@gmail.com




Re: Различия версий снапшотов

2012-03-05 Пенетрантность Alex Cherednichenko
Hello, Khorsun Vlad!
You wrote on Mon, 5 Mar 2012 13:55:59 +0200

> Не вижу ни единой проблемы или недоразумения в этом.

Никто ни на кого не наезжает.
Мои претензии к эбауту и отсутствию внятно прописанной связи с FB.
(историческая ретроспектива не в счет)



Re: Различия версий снапшотов

2012-03-05 Пенетрантность Khorsun Vlad

"Alex Cherednichenko" ...


Кто эти люди?
Из http://www.dqteam.com/about.html нихрена не понял.
Как они связаны с Firebird Development ?


   Конкретно DQTeam - делали новый сайт firebirdsql.org.

   Когда у нас не было возможности (по техническим причинам)
собирать ежедневные снапшоты, Сергей Мереуца предложил свою
помощь и линуксовые снапшоты "от dqteam" до сих пор живы.

   Не вижу ни единой проблемы или недоразумения в этом.

--
Хорсун Влад 





Re: Различия версий снапшотов

2012-03-05 Пенетрантность Khorsun Vlad

"reshetnyakvkt" ...

Здравствуйте. Решил обновить версию сервера. Так вот, чем принципиально
отличается снэпшоты выложеные здесь "http://www.dqteam.com/fb2/"; и здесь
"http://web.firebirdsql.org/download/snapshot_builds/linux/fb2.5/"; ?


   А кто вообще надоумил ставить снапшот на боевой сервер ? Или есть реальная
необходимость, например наступил на баг, исправленный в снапшоте ?


Догадываюсь что они собраны разными людьми, и в разное время. Т.е. содержат
разные изменения, и по сути представляют разные версии.


   Changelog читай.


Что же мне ставить в производство, чему отдать предпочтение?


   Официальную релизную сборку.

--
Хорсун Влад 





Re: Различия версий снапшотов

2012-03-05 Пенетрантность Dmitriy Kovalenko
>> Кто эти люди?

Sergey Mereutsa  serj собака dqteam

-- 
Banzai,
Dmitriy Kovalenko


Re: Различия версий снапшотов

2012-03-05 Пенетрантность Dmitriy Kovalenko
> Кто эти люди?

Republic of Moldova, Chisinau.

-- 
Banzai,
Dmitriy Kovalenko


Re: Различия версий снапшотов

2012-03-05 Пенетрантность Alex Cherednichenko
Hello, reshetnyakvkt!
You wrote on Mon, 5 Mar 2012 01:18:09 -0800 (PST)

> Здравствуйте. Решил обновить версию сервера. Так вот, чем принципиально
> отличается снэпшоты выложеные здесь "http://www.dqteam.com/fb2/"; и здесь
> "http://web.firebirdsql.org/download/snapshot_builds/linux/fb2.5/"; ?
> Догадываюсь что они собраны разными людьми, и в разное время. Т.е. содержат
> разные изменения, и по сути представляют разные версии. Что же мне ставить в
> производство, чему отдать предпочтение? Или тут уж "как карта ляжет"? Или
> вопрос откуда чаще качают?

Кто эти люди?
Из http://www.dqteam.com/about.html нихрена не понял.
Как они связаны с Firebird Development ?




Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL

2012-03-04 Пенетрантность Vlad Khorsun

(время мин:сек) Задача подключится на локальной машине к соседней базе и 
скопировать записи таблицы.
В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке 
переписал код.
Но каково было удивление, что прирост был не велик


/Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы ?
/С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D

1.коннект только локальный т.к. нужно максимум производительности
2.На момент вставки триггеров нет. В большинстве случаев я применяю тупой 
INSERT.


   Но не в нижеприведенном. Т.к. там UPDATE OR INSERT то
- либо индексы есть (и это уже не ускоряет вставку) и чем их больше, тем хуже,
- либо их нет - что есть смерть для UPDATE OR INSERT.


3.Сравниваю старый вариант построчно вставляемый мной и вариант полностью 
выполняемый блоком


   Во втором варианте ты исключил как минимум передачу параметров на сервер-
приёмник.

4.В моем варианте, я думал, что сервер тратит много времени на чтение строки из одной базы и вставку в другую базу. Оказалось что 
эти манипуляции настольно малы, что на это можно практически не обращать внимания.


Судя по загрузке процессора он не работает. Я думаю проблема в обмене данными с 
дисками.


   Не надо думать. Освой perfmon - и уже потом думай.

Вообще очень хотелось, чтобы кто нить поглядел место при вставке у сервера. Но с другой стороны не я один об этом подумываю, уже 
наверное смотрели. Просто когда 3 Гб база переливается в новую базу 4 часа становится тоскливо. Для любителей тестов скажу SSD на 
том же компе 1 час.


   Патология какая-то, явно что-то не так. Ресторится она у тебя тоже 4 часа
на этом же железе ?

Последнее время прогресс стоит на месте. Все железо от 2006 года работает практически также как и новое от 2011 года узкое место 
жесткий диск :).



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


/С чего бы это ?
По порядку я получаю такую конструкцию
'execute block returns (xCount integer) as'#13#10+
'%sParams%'#13#10+
'begin'#13#10+
'  FOR EXECUTE STATEMENT (''select %sGetF% from (%sSql%)'')'#13#10+
'ON EXTERNAL ''%sBase%'''#13#10+
'AS USER CURRENT_USER PASSWORD ''masterkey'' -- just for example'#13#10+
'WITH AUTONOMOUS TRANSACTION -- note autonomous transaction'#13#10+
'--for update'#13#10+
'INTO %sInsP%'#13#10+
'  do begin'#13#10+
'   UPDATE OR INSERT INTO %sTable% (%sInsF%)'#13#10+
' VALUES (%sInsP%)'#13#10+
' MATCHING (%sPK%);'#13#10+
'suspend;'#13#10+
'  end'#13#10+
'end;';


   Вот нафига тут эта каша ? Сложно было реальный запрос показать ? Тебе
помощь нужна или кому ?

подключаемся ко второй базе и вставляем в текущую записи. Предположим при вставке произошла ошибка, но надо продолжить. Наши 
действия без вывода вменяемой ошибке таковы WHEN ANY DO. С одной стороны достаточно но что за ошибка была? Ты скажешь убери WHEN 
ANY DO, но тогда нельзя будет продолжить.


   Я скажу - прочитай GDSCODE и выдай его SUSPEND'ом наружу для анализа,
если надо.

--
Хорсун Влад

PS xCount не вычисляется, накой он нужен 





Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL

2012-03-04 Пенетрантность Boltik Evgeny



"Khorsun Vlad"  сообщил(а) в новостях 
следующее:jislai$obn$1...@dough.gmane.org...


"Boltik Evgeny" ...

Добрый день.

(время мин:сек) Задача подключится на локальной машине к соседней базе и 
скопировать записи таблицы.

В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке 
переписал код.

Но каково было удивление, что прирост был не велик


/Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы 
?

/С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D

1.коннект только локальный т.к. нужно максимум производительности
2.На момент вставки триггеров нет. В большинстве случаев я применяю тупой 
INSERT.
3.Сравниваю старый вариант построчно вставляемый мной и вариант полностью 
выполняемый блоком
4.В моем варианте, я думал, что сервер тратит много времени на чтение строки 
из одной базы и вставку в другую базу. Оказалось что эти манипуляции 
настольно малы, что на это можно практически не обращать внимания.


Судя по загрузке процессора он не работает. Я думаю проблема в обмене 
данными с дисками. Вообще очень хотелось, чтобы кто нить поглядел место при 
вставке у сервера. Но с другой стороны не я один об этом подумываю, уже 
наверное смотрели. Просто когда 3 Гб база переливается в новую базу 4 часа 
становится тоскливо. Для любителей тестов скажу SSD на том же компе 1 час. 
Последнее время прогресс стоит на месте. Все железо от 2006 года работает 
практически также как и новое от 2011 года узкое место жесткий диск :).


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


/С чего бы это ?
По порядку я получаю такую конструкцию
'execute block returns (xCount integer) as'#13#10+
'%sParams%'#13#10+
'begin'#13#10+
'  FOR EXECUTE STATEMENT (''select %sGetF% from (%sSql%)'')'#13#10+
'ON EXTERNAL ''%sBase%'''#13#10+
'AS USER CURRENT_USER PASSWORD ''masterkey'' -- just for example'#13#10+
'WITH AUTONOMOUS TRANSACTION -- note autonomous transaction'#13#10+
'--for update'#13#10+
'INTO %sInsP%'#13#10+
'  do begin'#13#10+
'   UPDATE OR INSERT INTO %sTable% (%sInsF%)'#13#10+
' VALUES (%sInsP%)'#13#10+
' MATCHING (%sPK%);'#13#10+
'suspend;'#13#10+
'  end'#13#10+
'end;';

подключаемся ко второй базе и вставляем в текущую записи. Предположим при 
вставке произошла ошибка, но надо продолжить. Наши действия без вывода 
вменяемой ошибке таковы WHEN ANY DO. С одной стороны достаточно но что за 
ошибка была? Ты скажешь убери WHEN ANY DO, но тогда нельзя будет продолжить.


Ошибки переноса данных можно разделить на 2 вида.
1=Критические - перенос дальше не возможет. потеря нужных данных
2=Не критические - т.к. были допущены ошибки разработчика или не повлекут 
потерю важных данных(несвоевременное обновление базы данных или клиент не 
обслуживался но все же решил перейти на новую версию с возможной потерей 
неважных данных)


Желания.
1.Вообще хотелось бы чтобы в WHEN ANY DO можно было получить текст ошибки. И 
уже самому решить этот текст вернуть или свой.
2.И могу сделать тест создания базы данных который делался 1 минуту, а 
теперь 2 мин 30 сек. Где то в сервере что то поменялось однако ;)






Re: печалька для тестеров execute block+STATEMENT+ON EXTERNAL

2012-03-03 Пенетрантность Khorsun Vlad

"Boltik Evgeny" ...

Добрый день.

(время мин:сек) Задача подключится на локальной машине к соседней базе и 
скопировать записи таблицы.
В надежде ускорить вставку был в недоумении.
Думая что execute block+STATEMENT к другой базе даст прирост при вставке 
переписал код.
Но каково было удивление, что прирост был не велик


   Коннект локальный\сетевой ? На таблице-приёмнике есть триггеры\индексы ?
С чем вообще сравниваешь ? И какого прироста ты ожидал ? :-D


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


   С чего бы это ?

--
Хорсун Влад 





Re: Firebird 3.0.0.29767

2012-01-30 Пенетрантность Vlad Khorsun

"Anton Zibrov" ...

Добрый день, уважаемые!

Решил установить и помучать сабж...
получил:

Your user name and password are not defined. Ask your database administrator to 
set up a Firebird login.
Install incomplete, please read chapter "Initializing security database" in 
Quick Start Guide.

Quick Start Guide для 3.0 не нашел.


   fb_devel читать надо :)


Что делать?


   Добавить SYSDBA в security3.fdb вручную

   gsec -add sysdba -pw %new_password%

--
Хорсун Влад




Re: Проблемы при использовании временных таблиц с индексами

2012-01-20 Пенетрантность plasmorf
подготовить базу с примером пока не могу - зело занят, как освобожусь
непременно сделаю

Re: Проблемы при использовании временных таблиц с индексами

2012-01-20 Пенетрантность plasmorf
Доброе время суток.
Сервер FB 2.5.1 64 бит
есть база, в которой процедуры используют временные таблицы  ON COMMIT
DELETE ROWS с индексом по 3-м полям: integer, smallint, date
Проблема заключается в следующем:
Если после коннекта вызвать процедуру, использующую временную таблицу,
то первый раз все проходит нормально, однако если после выполнения
подтвердить или откатить транзакцию и в этом же коннекте запустить
процедуру еще раз, то вылазит ошибка: cannot add index, index root
page is full.
После пререподключения ситуация возобновляется - первый вызов
нормально, второй с ошибкой не смотря на то что они в разных
транзакциях


Re: Проблемы при использовании временных таблиц с индексами

2012-01-19 Пенетрантность Vlad Khorsun

"plasmorf" ...

Доброе время суток.
Сервер FB 2.5.1 64 бит
есть база, в которой процедуры используют временные таблицы  ON COMMIT
DELETE ROWS с индексом по 3-м полям: integer, smallint, date
Проблема заключается в следующем:
Если после коннекта вызвать процедуру, использующую временную таблицу,
то первый раз все проходит нормально, однако если после выполнения
подтвердить или откатить транзакцию и в этом же коннекте запустить
процедуру еще раз, то вылазит ошибка: cannot add index, index root
page is full.
После пререподключения ситуация возобновляется - первый вызов
нормально, второй с ошибкой не смотря на то что они в разных
транзакциях


   Воспроизводимый пример - где он ?

--
Хорсун Влад 





Re: Чудеса при замене SQL-сервера FB 1.5 32bit --> FB 2.5 64bit

2012-01-17 Пенетрантность Ovchinnikov Vasily

Vlad Khorsun пишет:

"Ovchinnikov Vasily" wrote ...


32-бит и 64-бит FB может работать с одной и той же БД, начиная с ODS 11.1
Младшие ODS не совместимы. Т.е. БД в ODS < 11.1 будет читаться только
32-битными версиями FB.

Спасибо, Влад
Главное - не собственно сами грабли, а знание их месторасположения :)


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Чудеса при замене SQL-сервера FB 1.5 32bit --> FB 2.5 64bit

2012-01-17 Пенетрантность Vlad Khorsun

"Ovchinnikov Vasily" wrote ...


   32-бит и 64-бит FB может работать с одной и той же БД, начиная с ODS 11.1
Младшие ODS не совместимы. Т.е. БД в ODS < 11.1 будет читаться только
32-битными версиями FB.

--
Хорсун Влад 





Re: Проблема с уникальным индексом на 2.5.1

2012-01-03 Пенетрантность Dmitry Yemanov

03.01.2012 17:06, A K пишет:



Что-то мне это напоминает :-) Спасибо за тестовую базу, будем
разбираться.


добрый день. не смотрели еще этот вопрос?


Смотрел, но решения пока нет.


--
Дмитрий Еманов



Re: Проблема с уникальным индексом на 2.5.1

2012-01-03 Пенетрантность A K

On 29.11.2011 15:16, Dmitry Yemanov wrote:



Что-то мне это напоминает :-) Спасибо за тестовую базу, будем разбираться.



добрый день. не смотрели еще этот вопрос?







Re: Что-то непонятное с left join

2011-12-23 Пенетрантность Tonal
23.12.2011 15:50, Dmitry Yemanov пишет:
>> Проверяю на существование дырок:
>> SQL>  select s.ID, s.ORD_NUM, s2.ID, s2.ORD_NUM
>> CON>  from SYMPTOMS s left outer join SYMPTOMS s2
>> CON>  on s.ORD_NUM + 1 = s2.ORD_NUM
>> CON>  where s.PARENT_ID = 450774 and s2.PARENT_ID = 450774
>> CON>  /*and s2.ID is null*/;
> Внеси "s2.PARENT_ID = 450774" в условие джойна. Иначе оно тебе
> отбрасывает все записи, не найденные в левом потоке (где s2.PARENT_ID IS
> NULL).
Спасибо.
От я затупил. :)
-- 
Александр Замараев



Re: Что-то непонятное с left join

2011-12-23 Пенетрантность Dmitry Yemanov

23.12.2011 12:50, Dmitry Yemanov пишет:


отбрасывает все записи, не найденные в левом потоке


В правом (внутреннем) потоке, конечно же :-)

--
Дмитрий Еманов



Re: Что-то непонятное с left join

2011-12-23 Пенетрантность Dmitry Yemanov

23.12.2011 11:31, Tonal пишет:
>
> Проверяю на существование дырок:
> SQL>  select s.ID, s.ORD_NUM, s2.ID, s2.ORD_NUM
> CON>  from SYMPTOMS s left outer join SYMPTOMS s2
> CON>  on s.ORD_NUM + 1 = s2.ORD_NUM
> CON>  where s.PARENT_ID = 450774 and s2.PARENT_ID = 450774
> CON>  /*and s2.ID is null*/;

Внеси "s2.PARENT_ID = 450774" в условие джойна. Иначе оно тебе 
отбрасывает все записи, не найденные в левом потоке (где s2.PARENT_ID IS 
NULL).



--
Дмитрий Еманов



Re: Путь к bin

2011-12-16 Пенетрантность Alexey Popov

Kirill Temnenkov wrote:


@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird 
Server\Instances

set reg_param=DefaultInstance
for /f "tokens=1,2,*" %%a in ('reg query "%reg_path%" /v 
"%reg_param%"') do if "%%a"=="%reg_param%" set reg_value=%%c

echo "%reg_value%"
pause


Спасибо. То что надо.



Re: Путь к bin

2011-12-16 Пенетрантность Ovchinnikov Vasily

Alexey Popov пишет:

Ovchinnikov Vasily wrote:


Кури утилиту REG

C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v 
DefaultInstance



Это хорошая идея, но над парсингом этого дела оператором for придётся 
попотеть...


Вот тебе выше Кирилл и написал как распарсить. Я поленился - он нет. ;)
За что ему огромное человеческое спасибо :)


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Путь к bin

2011-12-16 Пенетрантность Kirill Temnenkov
Ответ на первый вопрос:

@echo off
set reg_path=HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird 
Server\Instances
set reg_param=DefaultInstance
for /f "tokens=1,2,*" %%a in ('reg query "%reg_path%" /v 
"%reg_param%"') do if "%%a"=="%reg_param%" set reg_value=%%c
echo "%reg_value%"
pause

16 Декабрь 2011 г. 10:10:49, Alexey Popov писал:
> Может кто уже решал подобную задачу? Нужно сделать bat файл, который
> бы интенсивно использовал утилиты fb из каталога bin. Причём без
> участия узера. Проблема в том, что пути нет в PATH и ничего не
> работает. Если способ извлечь в батник пусть из реестра?
>
> Ещё вопросик. Есть ли способ вызывать isql не посредством указания
> input-файла, а через перенаправление ввода типа
> echo exit; | isql base.db
>




Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Alexey Popov пишет:

без файла, то на примере команды set
  echo set; >3 | isql <3

В принципе можно и так и так, вопрос в том что можно ли в isql обойтиcь без 
переноса строк?


А деже если и с переносами

echo set; >3
echo help; >>3
isql <3


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Путь к bin

2011-12-15 Пенетрантность Alexey Popov

Ovchinnikov Vasily wrote:


Кури утилиту REG

C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v 
DefaultInstance

HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances
DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\

Результат ее работы, как видно, надо будет парсить. Можно попытаться даже средствами FOR 


Это хорошая идея, но над парсингом этого дела оператором for придётся 
попотеть...



Есть, конечно.
echo exit; > ddd.sql
isql -i ddd.sql
del ddd.sql



Чё-то я поспешил...
 Если именно как ты хочешь без файла, то на примере команды set
 echo set; >3 | isql <3


В принципе можно и так и так, вопрос в том что можно ли в isql обойтиcь 
без переноса строк?




Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Yurij пишет:

А зачем так извращаться, оно же и так работает :
echo help; | isql


Дык... Людям надо доверять :) Я даже без задней мысли, что он прежде не проверил "в 
лоб" :)
Зато у него теперь несколько вариантов :)


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Ovchinnikov Vasily пишет:


В 2.x вроде (навскидку точно не помню), как ключик -q есть для isql, чтоб вывод 
спрятать.
Ну, это так, на всякий случай напоминаю.


Не, "гражданин соврамши!". -q только сообщение USE CONNECT ... прячет при 
старте.
Ну да ладно, вопрос-то не про это.

--
Regards,
Ovchinnikov Vasily
ova at tkvc ru

P.S. Во наговорился сам с собою-то... Пойду чаю выпью :)




Re: Путь к bin

2011-12-15 Пенетрантность Yurij
А зачем так извращаться, оно же и так работает :
echo help; | isql



Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Ovchinnikov Vasily пишет:

Ovchinnikov Vasily пишет:


Есть, конечно.
echo exit; > ddd.sql
isql -i ddd.sql
del ddd.sql


Чё-то я поспешил...
Если именно как ты хочешь без файла, то на примере команды set
echo set; >3 | isql <3


Ну или уж совсем полный пример:

Команда:
echo show database; >3|isql localhost:mydatabase -user ABC -password 123 <3

Результат:
Database:  localhost:mydatabase, User: ABC
SQL> Database: localhost:mydatabase
Owner: SYSDBA
PAGE_SIZE 8192
Number of DB pages allocated = 191
Sweep interval = 0
Forced Writes are ON
Transaction - oldest = 89442
Transaction - oldest active = 93312
Transaction - oldest snapshot = 93312
Transaction - Next = 93388
Default Character set: NONE
SQL>
C:\Program Files\Firebird\Firebird_1_5\bin>_

В 2.x вроде (навскидку точно не помню), как ключик -q есть для isql, чтоб вывод 
спрятать.
Ну, это так, на всякий случай напоминаю.

--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Ovchinnikov Vasily пишет:


Есть, конечно.
echo exit; > ddd.sql
isql -i ddd.sql
del ddd.sql


Чё-то я поспешил...
 Если именно как ты хочешь без файла, то на примере команды set
 echo set; >3 | isql <3


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Путь к bin

2011-12-15 Пенетрантность Ovchinnikov Vasily

Alexey Popov пишет:

Может кто уже решал подобную задачу? Нужно сделать bat файл, который бы 
интенсивно использовал утилиты fb из
каталога bin. Причём без участия узера. Проблема в том, что пути нет в PATH и 
ничего не работает. Если способ
извлечь в батник пусть из реестра?


Кури утилиту REG

C:\>reg QUERY "HKLM\SOFTWARE\Firebird Project\Firebird Server\Instances" /v 
DefaultInstance

HKEY_LOCAL_MACHINE\SOFTWARE\Firebird Project\Firebird Server\Instances
DefaultInstanceREG_SZC:\Program Files\Firebird\Firebird_1_5\

Результат ее работы, как видно, надо будет парсить. Можно попытаться даже 
средствами FOR


Ещё вопросик. Есть ли способ вызывать isql не посредством указания input-файла, 
а через перенаправление ввода
типа
echo exit; | isql base.db


Есть, конечно.
echo exit; > ddd.sql
isql -i ddd.sql
del ddd.sql


--
Regards,
Ovchinnikov Vasily
ova at tkvc ru





Re: Ubuntu и QIBASE - драйвер Firebird для Qt

2011-12-15 Пенетрантность Past

> Описаная трабла характерна именно для Ubuntu и
> производных, т. к. если
> верить changelog-у в исходном Debian-овском пакете libqt4-sql-ibase
> собирается. А в Ubuntu его отдельным местом отключают...
> 
> Причём ежели скачать исходники Qt и включить его
> обратно, то всё
> собирается «на ура».
Ответ неверный, интербейсовского драйвера нет в убунте потому что qt4 идет в
репозитории main, а firebird идет в репозитории contrib или как его там, а
полиси убунтовские запрещают зависимости main от contrib




Re: Глюки в рекурсивном запросе

2011-12-12 Пенетрантность Dmitry Yemanov

13.12.2011 8:12, Tonal пишет:


Похоже.


Дык проверь. Скачай последний снапшот 3.0, создай новую базу и выполни 
свой тестовый пример.



--
Дмитрий Еманов



Re: Глюки в рекурсивном запросе

2011-12-12 Пенетрантность Dmitry Yemanov

13.12.2011 8:30, Tonal пишет:


Вроде бы не было ограничений про неименованные вычисляемые поля в
подзапросах.
Или я опять что-то пропустил?


В derived table все столбцы должны быть именованы, так всегда было.


--
Дмитрий Еманов




Re: Глюки в рекурсивном запросе

2011-12-12 Пенетрантность Tonal
Ещё странность на похожем запросе:
Добавим в корневой подзапрос неименованную вычисляемую колонку
with recursive
SYM as (
  select sr1.ID, sr1.PARENT_ID, count(*) --  Добавили count(*)
  from SYMPTOMS sr1
  group by 1, 2
),
TREE as (
  select 1 as LEV, sp.ID, sp.PARENT_ID
  from SYM sp where sp.ID = 450797
  union all
  select t.LEV + 1, st.ID, st.PARENT_ID
  from SYM st inner join TREE t on st.PARENT_ID = t.ID
)
select
  t.LEV, t.ID
from TREE t

Получаем ошибку:
Message: isc_dsql_prepare failed

SQL Message : -104
Invalid token

Engine Code: 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Invalid command
no column name specified for column number 3 in derived table SP

Ежели колонку проименовать запрос выполнится.
Вроде бы не было ограничений про неименованные вычисляемые поля в
подзапросах.
Или я опять что-то пропустил?

-- 
Александр Замараев



Re: Глюки в рекурсивном запросе

2011-12-12 Пенетрантность Tonal
12.12.2011 21:01, Khorsun Vlad пишет:
> "Tonal" ...
>> Наткнулся на такую глючу.
>Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД.
--DDL:
CREATE DOMAIN D_ID AS integer NOT NULL;
CREATE DOMAIN D_ID_OR_NULL AS integer;

CREATE TABLE SYMPTOMS (
  ID D_ID,
  PARENT_ID D_ID_OR_NULL,
  CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (PARENT_ID) REFERENCES SYMPTOMS (ID)
);

--Datas
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450797', null);
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450798', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450799', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450800', '450798');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450801', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450802', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450803', '450801');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645590', '450797');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645591', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645592', '645590');
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('645593', '645592');

> PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ?
Похоже. Только в моём случае создание уникальности по обоим полям не влияет.
Создавал ткую:
alter table SYMPTOMS add constraint UNQ_ID_PARENT unique (ID, PARENT_ID)

-- 
Александр Замараев



Re: Глюки в рекурсивном запросе

2011-12-12 Пенетрантность Khorsun Vlad

"Tonal" ...

Наткнулся на такую глючу.
В запросе ниже


   Хорошо бы, чтобы DLL мог выполниться. На новой пустой БД.

--
Хорсун Влад

PS http://tracker.firebirdsql.org/browse/CORE-3683 - не оно ? 





Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

2011-12-02 Пенетрантность Khorsun Vlad

"reshetnyakvkt" ...


Сама ось не висит, выполняет команды и т.д. А к серверу firebird не
присоединится, все соединения уходят в никуда, т.е. висят без ответа на
ошибку коннекта или другое.


   Бектрейс висячего процесса и копия лок-таблицы могут пролить свет
на эту тайну

--
Хорсун Влад 





Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

2011-12-02 Пенетрантность Dmitry Yemanov

02.12.2011 15:05, reshetnyakvkt пишет:


Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с
перезагрузкой оси.
Сама ось не висит, выполняет команды и т.д. А к серверу firebird не
присоединится, все соединения уходят в никуда, т.е. висят без ответа на
ошибку коннекта или другое.


А уже установленные на этот момент соединения продолжают работать? Или 
тоже виснут наглухо? Или прибиваются скриптом перед его подвисом?



Такой скипт после установки новой версии FB выполнялся дважды оба раза с
печальным итогом.


А если убрать FOR-цикл с удаленным выполнением запросов, т.е. гасить 
только коннекты к своей базе?


Если будет работать, то проблема не в MON$, а в коннектах к другим 
базам, см. ниже.



Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32.


Причем тут клиент? Версия клиентской библиотеки на это никак не влияет.


Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу
предположить что дело может быть в попытке поднять их в память которой
только 8Гб, и сервер уходит в глубокий своппинг.


Такое возможно, ведь EXECUTE STATEMENT не сразу закрывает свой коннект. 
Какой размер страничного кеша установлен для этих баз?



Хотя раньше такого не наблюдалось.


Может настройки какие-то менялись?


Не знаю что ещё добавить. Если скрипт работает у других


Точно такого же (с коннектами к другим базам) наверное ни у кого нет :-) 
А вот простой DELETE FROM MON$ATTACHMENTS есс-но работает.



Дмитрий



Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

2011-12-02 Пенетрантность reshetnyakvkt
Во всех случаях сервер установлен из rpm. Старый удалялся ч/з rpm -e, с
перезагрузкой оси.
Сама ось не висит, выполняет команды и т.д. А к серверу firebird не
присоединится, все соединения уходят в никуда, т.е. висят без ответа на
ошибку коннекта или другое.
Такой скипт после установки новой версии FB выполнялся дважды оба раза с
печальным итогом.
Права на /tmp/firebird (rwx-rwx-__ [firebird/firebird]), вроде нормально.
Висят в нем 8 файлов суммарно 8мб.
Вот еще - на клиенте установлен снэпшот FB2.5.1.26353-0_win32.
Суммарный объем файлов баз к которым применяется скрипт около 28Гб, могу
предположить что дело может быть в попытке поднять их в память которой
только 8Гб, и сервер уходит в глубокий своппинг.
Хотя раньше такого не наблюдалось.
Не знаю что ещё добавить. Если скрипт работает у других, то подожду
следущего раза и если ситуация повторится, буду отслеживать кто виноват
пробуя с разными базами. Может отчленять по кускам.

--
View this message in context: 
http://firebird.1100200.n4.nabble.com/delete-from-MON-ATTACHMENTS-where-MON-ATTACHMENTS-MON-ATTACHMENT-ID-CURRENT-CONNECTION-tp4145993p4146299.html
Sent from the firebird-russian mailing list archive at Nabble.com.

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_ID<>CURRENT_CONNECTION

2011-12-02 Пенетрантность Dmitry Yemanov

02.12.2011 13:50, reshetnyakvkt пишет:


До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64*


Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов?


После установки *FirebirdSS-2.5.1.26351-0.amd64*


Как был установлен? Из RPM или из tar.gz или собран и установлен из сорцов?


такая конструкция валит
сервер наглухо. Приложения выполняющее этот запрос висит не реагируя


Так валит сервер или вешает коннект, выполняющий запрос? Это совсем 
разные вещи. Как при этом себя чувствуют остальные коннекты?



Это уже второй раз так случается и прослеживается закономерность.


Т.е. это выполнялось всего дважды и оба раза висло или же выполнялось 
многократно, но висло всего дважды?


Какие права даны на каталог /tmp/firebird?


Вопрос к разработчикам что происходит. Если конструкция с
"MON$ATTACHMENTS.MON$ATTACHMENT_ID" больше не работает, то подскажите как
теперь без последствий отключать непослушные коннекты?


У всех остальных она работает.


Дмитрий



Re: new / delete в UDF

2011-11-29 Пенетрантность Vladimir
>Проблема в том, что по умолчанию линкер gcc экспортирует все ф-ции.
> Соответственно, UDF цепляет delete движка (embedded коннект), или isql.
> Движок в 2.5 вроде как уже поправили на этот счёт, но утилиты по прежнему
> всё выставляют наружу.

Но тогда ведь и new бы цеплялась?
Или в чем-то условия для этих двух операторов отличаются?

Моя громоздкая UDF заработала.
Еще раз большое спасибо за решение.

С уважением, Владимир.



Re: Проблема с уникальным индексом на 2.5.1

2011-11-29 Пенетрантность Dmitry Yemanov

29.11.2011 16:54, Yurij пишет:

Забавно:
При создании индекса оно валится вот на этих двух строках:

BANKKEY BANKCODE BANKMFO SWIFT BANKBRANCH
148517044 749 153001749 
150695489 749 153001749  

Т.е. создание индексов не различает пустую строку и NULL в BANKBRANCH, а
group by - различает.


Что-то мне это напоминает :-) Спасибо за тестовую базу, будем разбираться.


--
Дмитрий Еманов



Re: Проблема с уникальным индексом на 2.5.1

2011-11-29 Пенетрантность Yurij
Забавно:
При создании индекса оно валится вот на этих двух строках:

BANKKEY BANKCODE BANKMFO  SWIFT
BANKBRANCH
148517044 749  153001749
150695489 749  153001749   


Т.е. создание индексов не различает пустую строку и NULL в BANKBRANCH, а 
group by - различает.


Re: Проблема с уникальным индексом на 2.5.1

2011-11-29 Пенетрантность A K


Ок, пакуй БД и выкладывай куда-нить для ознакомления.
Если там ценные данные или их просто много, можно дропнуть не
нужные таблицы и выложить бекап.



ftp://gs.selfip.biz
user: temp
passw: temp

там архив с бэкапом. при разбэкапе понадобится УДФ-ка

http://gsbelarus.com/gs/modules.php?name=Downloads&d_op=getit&lid=63

она же, только 64 бита:

http://gsbelarus.com/gs/modules.php?name=Downloads&d_op=getit&lid=95

индекс, с которым возникает проблема:

GD_X_BANK_BANKCODE

скажите, когда снимите с ФТП.




Re: new / delete в UDF

2011-11-29 Пенетрантность Vlad Khorsun

"Vladimir" ...


Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо
rtl-ных new/delete подставляет какие-то левые.



Тут немного непонятно.
Если в моей udf используются new/delete от firebird, то почему они
приводят к ошибке?
Может быть, дело в другом?
Например, такая ситуация.
Firebird работает, что-то размещает своим new.
Потом загружается моя библиотека, и firebird с этого момента
переключается на загруженные с ней new, delete из libstdc++
При этом использует чужой delete для чего-то, размещенного ранее своим
new.


   Именно это и было моим первым предположением. Только оно касалось
экспортированных new\delete из UDF.

--
Хорсун Влад 





Re: new / delete в UDF

2011-11-29 Пенетрантность Vlad Khorsun

"Vladimir" ...

Сегодня получился положительный результат.
Большое спасибо за советы.

Вчера долго не удавалось настроить сетевой коннект.
Применял разные рекомендации, которые находил.
Вероятно, сделал что-то лишнее.
В firebird.log были записи
INET/inet_error: send errno = 32
Версия точно Firebird CS 2.1.3.18185-0.ds1-6built1

Сегодня вернулся к исходной точке и применил минимум настроек.
UDF отработала.
При этом управление в перегруженные функции new, delete не передается.
Буду проверять на более сложных примерах.

На локальном коннекте ситуация не изменилась - Segmentation fault на
операторе delete.

Проверить версию 2.5 быстро точно не получится.
В менеджере пакетов ubuntu ее нет, а другой путь установки сложнее,
опыт в Linux у меня небольшой.
Если надо - попробую проверить.


   Желательно


Можно ли сейчас предположить, есть ли шансы добиться, чтобы new,
delete заработали на локальном коннекте?
Или не стоит и пытаться?
В чем причина?


   http://tracker.firebirdsql.org/browse/CORE-3677

   Проблема в том, что по умолчанию линкер gcc экспортирует все ф-ции.
Соответственно, UDF цепляет delete движка (embedded коннект), или isql.
Движок в 2.5 вроде как уже поправили на этот счёт, но утилиты по прежнему
всё выставляют наружу.

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

--
Хорсун Влад 





Re: new / delete в UDF

2011-11-29 Пенетрантность Vladimir
>> Вариант 3. Пытаюсь перегрузить операторы new и delete.
> Попробуй в этом варианте сделать операторы инлайновыми или разместить их
> в неименованном пространстве имён.
> Т. е. скрыть от линкера.


Пробовал объявить свои перегруженные операторы как inline - все равно
в udf управление на них не передается.


> Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо
> rtl-ных new/delete подставляет какие-то левые.


Тут немного непонятно.
Если в моей udf используются new/delete от firebird, то почему они
приводят к ошибке?
Может быть, дело в другом?
Например, такая ситуация.
Firebird работает, что-то размещает своим new.
Потом загружается моя библиотека, и firebird с этого момента
переключается на загруженные с ней new, delete из libstdc++
При этом использует чужой delete для чего-то, размещенного ранее своим
new.


С уважением, Владимир.


Re: new / delete в UDF

2011-11-29 Пенетрантность Vladimir
Сегодня получился положительный результат.
Большое спасибо за советы.

Вчера долго не удавалось настроить сетевой коннект.
Применял разные рекомендации, которые находил.
Вероятно, сделал что-то лишнее.
В firebird.log были записи
INET/inet_error: send errno = 32
Версия точно Firebird CS 2.1.3.18185-0.ds1-6built1

Сегодня вернулся к исходной точке и применил минимум настроек.
UDF отработала.
При этом управление в перегруженные функции new, delete не передается.
Буду проверять на более сложных примерах.

На локальном коннекте ситуация не изменилась - Segmentation fault на
операторе delete.

Проверить версию 2.5 быстро точно не получится.
В менеджере пакетов ubuntu ее нет, а другой путь установки сложнее,
опыт в Linux у меня небольшой.
Если надо - попробую проверить.

Можно ли сейчас предположить, есть ли шансы добиться, чтобы new,
delete заработали на локальном коннекте?
Или не стоит и пытаться?
В чем причина?

С уважением, Владимир.

Re: new / delete в UDF

2011-11-29 Пенетрантность Vlad Khorsun

"Vladimir" ...

С сетевым коннектом ошибка проявляется по-другому, и isql при этом не
падает.

SQL> SELECT TestInsert(333) from RDB$Database;

 TESTINSERT

Statement failed, SQLCODE = -902
Error reading data from the connection.
SQL> quit;


   Это действительно 2.1.3 ? Не 2.0.х ?
В firebird.log на сервере есть что-то ?
Есть возможность проверить 2.5 ?

--
Хорсун Влад 





Re: new / delete в UDF

2011-11-28 Пенетрантность Tonal
28.11.2011 18:27, Vladimir пишет:
> Вариант 3. Пытаюсь перегрузить операторы new и delete.
Попробуй в этом варианте сделать операторы инлайновыми или разместить их
в неименованном пространстве имён.
Т. е. скрыть от линкера.

Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо
rtl-ных new/delete подставляет какие-то левые.

Попробуй запустить под strace и/или gdb.
-- 
Александр Замараев



Re: new / delete в UDF

2011-11-28 Пенетрантность Vladimir
С сетевым коннектом ошибка проявляется по-другому, и isql при этом не
падает.

SQL> SELECT TestInsert(333) from RDB$Database;

  TESTINSERT

Statement failed, SQLCODE = -902
Error reading data from the connection.
SQL> quit;


С локальным коннектом isql падал.

SQL> SELECT TestInsert(333) from RDB$Database;
Segmentation fault
root@ap:/home/v/TestCallAll#


С уважением, Владимир.



Re: new / delete в UDF

2011-11-28 Пенетрантность Vlad Khorsun

"Vladimir" ...

Да, все в isql с локальным коннектом.
Имеет смысл попробовать сетевой коннект?


   Да

--
Хорсун Влад 





Re: new / delete в UDF

2011-11-28 Пенетрантность Vladimir
Да, все в isql с локальным коннектом.
Имеет смысл попробовать сетевой коннект?

С уважением, Владимир.

Re: new / delete в UDF

2011-11-28 Пенетрантность Khorsun Vlad

"Vladimir" ...

   А каким образом проверяется работоспособность UDF ?
Запросы выполняются в isql с локальным коннектом ?
Сетевой коннект не пробовал ?

--
Хорсун Влад 





Re: new / delete в UDF

2011-11-28 Пенетрантность Vladimir
Firebird CS 2.1.3.18185

g++ версии 4.4.3-4ubuntu5


Отладчиком пользоваться не пытался.

Проверил на простом примере. Получается следующее.

Вариант 1. Без new и delete.

#include 
long TESTINSERT(long *theArg)
{
  long* aTestItem = (long*) malloc(sizeof(long));
  free(aTestItem);

  long aResult = 777;
  return(aResult);
}

Такая UDF успешно отрабатывает.


Вариант 2. Ошибка с new и delete.

long TESTINSERT(long *theArg)
{
  long* aTestItem = new long;
  delete aTestItem;

  long aResult = 778;
  return(aResult);
}

Ошибка Segmentation fault.


Вариант 3. Пытаюсь перегрузить операторы new и delete.

#include 
#include 

void* operator new(size_t sz)
{
  void* m = malloc(sz);
  return m;
}

void operator delete(void* m)
{
  free(m);
}

long TESTINSERT(long *theArg)
{
  long* aTestItem = new long;
  delete aTestItem;

  long aResult = 779;
  return(aResult);
}
Ошибка Segmentation fault.


Если функция TESTINSERT вызывается не как UDF, а из обычной программы
- все три варианта работают.

Если подключить тестовый вывод, то в третьем варианте видно следующее.

При вызове из обычной программы отрабатывают перегруженные операторы.
Все происходит, как предполагалось.

При вызове UDF перегруженные операторы игнорируются. Выполнение туда
не передается.
Оператор new (не перегруженный) проходит без ошибки.
На операторе delete UDF падает.


С уважением, Владимир.







Re: Проблема с уникальным индексом на 2.5.1

2011-11-28 Пенетрантность Khorsun Vlad

"A K" ...

   Ок, пакуй БД и выкладывай куда-нить для ознакомления.
Если там ценные данные или их просто много, можно дропнуть не
нужные таблицы и выложить бекап.

--
Влад 





Re: Проблема с уникальным индексом на 2.5.1

2011-11-28 Пенетрантность A K

On 28.11.2011 10:54, Khorsun Vlad wrote:


Сначала на вопросы ответь :)


1. оба поля VARCHAR(20) CHARACTER SET WIN1251
2. первое поле NOT NULL
3. второе поле сейчас не содержит НУЛЛов. Они заменены на пустые строки.
4. первое поле содержит НЕ УНИКАЛЬНЫЕ значения
5. неуникальных коомбинаций по первому и второму полям нет. Проверено

  SELECT f1, f2, count(*) FROM t GROUP BY 1, 2 HAVING count(*) > 1

возвращает пустой набор.

6. при попытке создать уникальный индекс по этим двум полям -- ошибка.
7. база восстановлена из архива gbak-om с соответствующим ключем для
отключения индексов
8. сервер 2.5.2 из снэпшотов
9. лично не проверял, но клиенты говорят, что у них восстанавливается.
у них 2.5.0.




Re: new / delete в UDF

2011-11-28 Пенетрантность Khorsun Vlad

"Vladimir" ...

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


   Какого-такого редактора ?


Пробовал --no-export-dynamic  --exclude-libs, никакого эффекта.


   Какая версия Firebird ?

   Есть возможность пройтись отладчиком по коду UDF и посмотреть - что
за delete он вызывает?

--
Хорсун Влад 





Re: Проблема с уникальным индексом на 2.5.1

2011-11-28 Пенетрантность Khorsun Vlad

"A K" ...

В базе есть уникальный индекс по двум строковым полям.


   Тип данных какой ? И чарсет.


База перестала восстанавливаться из архива.


   А когда восстанавливалась ?
На 2.5.0 восстанавливается ?


Восстанавливаем без индексов.
Пытаемся воссоздать этот индекс -- ругается на наличие повторяющихся строк. Но,

1) запрос с группировкой показывает что повторяющихся строк НЕТ.
2) более того, первое поле в индексе содержит только уникальные значения.


   Откуда это известно ? На первое поле уникальный индекс даёт создать ?


3) была идея, что наличие NULL в некоторых строках во второй колонке
индекса приводит к такому эффекту, но замена NULL на пустые строки
все равно не дает создать индекс.

Что за проблема? Если что, базу могу на какой ФТП залить.


   Сначала на вопросы ответь :)

--
Хорсун Влад 





Re: Проблема с уникальным индексом на 2.5.1

2011-11-24 Пенетрантность A K

проблема присутствует и в снэпшоте 2.5.2 от 24.11.2011



Re: Проблема с уникальным индексом на 2.5.1

2011-11-23 Пенетрантность A K

проблема похожа на:

http://tracker.firebirdsql.org/browse/CORE-3660



Re: Проблема с уникальным индексом на 2.5.1

2011-11-23 Пенетрантность A K



Для поиска повторяющихся строк нужно отключить использование индекса в запросе.


у меня итак база восстановлена без единого индекса.



RE: Проблема с уникальным индексом на 2.5.1

2011-11-23 Пенетрантность Vadim Mescheryakov
>1) запрос с группировкой показывает что повторяющихся строк НЕТ.
>2) более того, первое поле в индексе содержит только уникальные значения.
>3) была идея, что наличие NULL в некоторых строках во второй колонке
>индекса приводит к такому эффекту, но замена NULL на пустые строки
>все равно не дает создать индекс.

Для поиска повторяющихся строк нужно отключить использование индекса в запросе.
Например

select id, count(*) from restaurant_accounts
group by id
having count(id) > 1
plan (restaurant_accounts natural)


С уважением, Мещеряков Вадим

директор ООО "Комплексные Системы" 
454021 г. Челябинск ул. 40 лет Победы 31, 77
Тел: +7 (351) 2807917
Моб: +7 922 6395170
Web: www.del-fin.ru
ICQ: 343-554-572
SKYPE: vadimmescheryakov




Re: new / delete в UDF

2011-11-21 Пенетрантность Vladimir
Спасибо за совет.
Очень было похоже, что это может помочь, но никакие опции редактора не
изменили ситуацию.
Пробовал --no-export-dynamic  --exclude-libs, никакого эффекта.

С уважением, Владимир.

Re: new / delete в UDF

2011-11-21 Пенетрантность Vladimir


On Nov 18, 11:08 am, "Khorsun Vlad"  wrote:
> "Vladimir" ...
>
> > !
>
> > Linux UDF, gcc,
> > :
>
> >  long* aTestItem = new long;
> >  delete aTestItem;
>
> > Segmentation fault delete.
>
>     ,
> .so ӣ .
>
> --


Re: new / delete в UDF

2011-11-17 Пенетрантность Khorsun Vlad

"Vladimir" ...

Здравствуйте!

При попытке в Linux использовать UDF, собранную в gcc, столкнулся со
следующим:

 long* aTestItem = new long;
 delete aTestItem;

вызывает ошибку Segmentation fault на операторе delete.


   Насколько я помню, нужно явно сказать линкеру не экспортировать
из .so всё подряд.

--
Хорсун Влад




Re: Тозмоза простейших запросов

2011-11-15 Пенетрантность Alexey Popov
Пока возникло серьёзное подозрение на слубжу восстановление системы. Она 
включена и в файле filelist.xml было расширение gdb. Вероятно эта слубжа 
раз в сутки блокировала файл БД для создания точки восстановления...




Re: Тозмоза простейших запросов

2011-11-12 Пенетрантность Alexey Popov

Vlad Khorsun wrote:


   У винды есть perfmon, который ты конечно же настроил и изучаешь логи
в моменты торможения...


Пока не могу, т.к. управляю этим сервером по эл. почте.
Нужно составить текстовую инструкцию админу широкого профиля по 
настройке этого перфмона...





Re: Тозмоза простейших запросов

2011-11-12 Пенетрантность Vlad Khorsun

"Alexey Popov" ...

Может какие службы у винды есть типа дефрагметатора/индексатора?
Кстати, расширение файла gdb. Может оно влияет?


   У винды есть perfmon, который ты конечно же настроил и изучаешь логи
в моменты торможения...

--
Хорсун Влад 





Re: Тозмоза простейших запросов

2011-11-12 Пенетрантность Alexey Popov

Может какие службы у винды есть типа дефрагметатора/индексатора?
Кстати, расширение файла gdb. Может оно влияет?



Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Alexey Popov

Arioch wrote:

какое-нибудь обновление антивируса/файрвола, которое на 20 секунд  
блокирует TCP/IP ?


Период чуть больше 24 часов. Инета там нет.



Re: Не выйти из isql позле вызова UDF в Linux

2011-11-11 Пенетрантность Arioch
В письме от Thu, 20 Oct 2011 19:30:32 +0400, Vsevolod  
 сообщал:


  Если кому интересно - новости нашего городка. В варианте, описаном  
выше,

добился нормальной работы тестовой библиотеки, когда поменял клиентскую
библиотеку fbclient.dll на версию от FB 2.1.
 Куда крестьянину податься теперь ...


Возможно, описать это на http://tracker.firebirdsql.org/browse/CORE-3651
По крайней мере отслеживать :-)

--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Arioch
В письме от Fri, 11 Nov 2011 15:30:35 +0400, Alexey Popov  
 сообщал:


Я писал, что лог поймал торможение запроса, который вообще ничего не  
читает: execute block as begin post_event 'my_event'; end


какое-нибудь обновление антивируса/файрвола, которое на 20 секунд  
блокирует TCP/IP ?


--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Alexey Popov

Khorsun Vlad wrote:


Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.



   Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить
её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее.


Кэшировать всю особо не нужно, т.к. интенсивно юзается инфа только за 
последнии 1-2 месяца. Да и половина базы в редко юзаемых блобах.


Со свипом проблем никогда не было. Реалтайм от относительный. Т.е. 
обычно insert проходит мгновенно, но судя по логу примерно раз в сутки 
тормозит на 20-40 секунд. Что это - х.з. Может винда в дикий своп ухоит.


По идее свип вообще должен редко запускаться, т.к. откаты и обрывы 
соединений крайне редки в нормальный работе.


Свип может много писать на диск (если мусора много). 


Мусора много нет. В основном insert-select.


Т.к. диск один, то
запросы на чтение будут сильно проседать во время такой записи. С другой
стороны, если добиться полного кеширования БД в файловом кеше, то запросов
на чтение просто не станет.


Я писал, что лог поймал торможение запроса, который вообще ничего не 
читает: execute block as begin post_event 'my_event'; end



   Так что я бы попробвал добить память до 3GB и тянуть всю БД в кеш при
старте системы. Например, с помощью того же gstat -r, читающего всё, кроме
разве что блобов.


База там крутится круглосуточно без перерыва, и с ней работают несколько 
служб. Рестарт крайне редкий. b/r не делался уже полтора года.




Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Khorsun Vlad

"Alexey Popov" ...


   OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся.


Сама по себе долгоиграющая может появится штатно, т.к. юзеры днём там пасутся.


   Ну и что ?


Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на 
запросе
execute block as begin post_event 'my_event'; end


   Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ?


Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.


   Если ты хочешь кешировать БД целиком, то по памяти ты на грани. Добавить
её не помешает. Если реалтайм, то почему авто-свип не запрещён ? Далее.
Свип может много писать на диск (если мусора много). Т.к. диск один, то
запросы на чтение будут сильно проседать во время такой записи. С другой
стороны, если добиться полного кеширования БД в файловом кеше, то запросов
на чтение просто не станет.

   Так что я бы попробвал добить память до 3GB и тянуть всю БД в кеш при
старте системы. Например, с помощью того же gstat -r, читающего всё, кроме
разве что блобов.

--
Хорсун Влад 





Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Alexey Popov

Khorsun Vlad wrote:


Виноват оказался sweep.


   Откуда это видно ?


Сорри, тут я ступил, посмотрел на next


   OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся.


Сама по себе долгоиграющая может появится штатно, т.к. юзеры днём там 
пасутся.


Основной вопрос в том, почему sweep полностью блокирует работу сервера 
даже на запросе

execute block as begin post_event 'my_event'; end


   Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ?


Памяти 2Гб, диск один SATA2. Но и база то мелкая, зато реалтайм.



Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Khorsun Vlad

"Alexey Popov" ...

Ранее я писал:


Есть БД под FB2.0.3 SS. С ней постоянно работают несколько служебных
программ и периодически пользователи. В служебных программах
происходят только простейшие select/insert, которые выполняются
обычно мгновенно. Там так же сделана сигнализация (вывод в лог) если
какой то запрос будет выполняться слишком долго. И иногда в
попадаются единичные записи о слишком долгом выполнении таких
примитивных sql запросов - до 44 секунд! Время суток - уже когда
пользователи ушли домой, серьёзной нагрузки нет. Запись о замедлении
есть с разных клиентов в одно и тоже время, один из клиентов
находится там где и сервер БД, поэтому проблемы с сетью как бы
отметаются.


Виноват оказался sweep.


   Откуда это видно ?


Вот наиболее важные свойства базы:

Database size : 1409 Mb
Page size 8192
ODS version 11.0
Oldest transaction 67773710
Oldest active 67773711
Oldest snapshot 67773711
Next transaction 67786537
Sweep interval: 2

Как вижно разница скоро достигнет 2 и сработает sweep. Почему транзацкции застревают - это отдельный вопрос, ранее такого не 
было.

Может быть rollback виноват???


   OIT застревает или от роллбека, или от лимбо. Это азы.
Но в данном случае я не вижу застрявшего OIT, ибо OAT = OIT + 1, т.е.
есть долгоиграющая тр-ция с номером 67773711. С ней и разбирайся.


Основной вопрос в том, почему sweep полностью блокирует работу сервера даже на 
запросе
execute block as begin post_event 'my_event'; end
?


   Дисковая никакая ? gstat -r давно смотрел ? Сколько памяти в наличии ?

--
Хорсун Влад 





Re: Тозмоза простейших запросов

2011-11-11 Пенетрантность Alexey Popov

Alexey Popov wrote:

Как вижно разница скоро достигнет 2 и сработает sweep. Почему 
транзацкции застревают - это отдельный вопрос, ранее такого не было.

Может быть rollback виноват???


Получается что после sweep разница обнуляется продолжается сразу расти 
вновь? Что это может значить?




Re: перестают поступать события

2011-11-10 Пенетрантность Alexey Popov

Alexey Popov wrote:

Есть FB2.0 SS и служба работающая на этом же компе. Служба подписывается 
на события и слушает их. Всё это работает много дней. В какой то момент 
перестают доходить события до службы. Для проверки этой гипотезы сделано 
тестовое событие, которые регулярно по таймеру генерируется самой 
службой и отслеживается появление соответствующего уведомления. И 
действительно, события перестают доходить. В чём может быть причина?

Ранее такого вроде бы не наблюдалось.

Чисто технически, внутри там вроде дополнительно TCP соединение, по 
которому передаются события. Предположим, что оно по каким то причинам 
протухло... Кто вернёт ошибку в этом случае?



Итак, после замены IP на 127.0.0.1 в течении ~20 суток непрерывной 
работы проблема пока не появляется.


Архитектурная проблема в API что нет способа определить отвал соединения 
для эвентов при асинхронной работе с ними.






Re: Оптимизатор 2.5.2 : учёт взаимодействия FK, JOIN, DISTINCT, GROUP BY в простейших случаях

2011-11-08 Пенетрантность Dmitry Yemanov

08.11.2011 15:52, Arioch пишет:


В ту же копилку, взаимодействие агрегатов и where

select m.object as object_idx, max (m.turn) as max_turn
from metrics m
/* where m.turn > 45 */
group by m.object
having max (m.turn) > 45
order by 2 descending

select m.object as object_idx, max (m.turn) as max_turn
from metrics m
where m.turn > 45
group by m.object
/* having max (m.turn) > 45 */
order by 2 descending


Я даже комментировать это не хочу, уж извините.


--
Дмитрий Еманов



Re: Оптимизатор 2.5.2 : учёт взаимодействия FK, JOIN, DISTINCT, GROUP BY в простейших случаях

2011-11-08 Пенетрантность Arioch
В письме от Tue, 08 Nov 2011 15:38:30 +0400, Arioch  
 сообщал:



Таблица Objects (integer idx not null Primary key и еще столбцы)
Таблица Metrics (integer idx not null Primary key, integer Object not  
null -> FK на Objects.idx, double Turn индексированное);




В ту же копилку, взаимодействие агрегатов и where

select m.object as object_idx, max (m.turn) as max_turn
 from  metrics m
/* where m.turn > 45 */
group by m.object
having max (m.turn) > 45
order by 2 descending
---
PLAN SORT ((M ORDER FK_METRICS_1))
Indexed Reads: 9351



select m.object as object_idx, max (m.turn) as max_turn
 from  metrics m
where m.turn > 45
group by m.object
/* having max (m.turn) > 45 */
order by 2 descending
--
PLAN SORT ((M ORDER FK_METRICS_1 INDEX (METRICS_IDX2)))
Indexed Reads: 1352

--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-08 Пенетрантность Dmitry Yemanov

07.11.2011 16:35, Arioch пишет:


В случае ошибки вероятно исключение всплывает наверх и проплывает через
код, который знает из каких строк он исходные значения взял.


Никакой код об этом не знает, ибо работает на основе BLR. А привязка BLR 
к SQL существует лишь на уровне команд целиком.



--
Дмитрий Еманов




Re: Ubuntu и QIBASE - драйвер Firebird для Qt

2011-11-07 Пенетрантность Tonal
08.11.2011 03:09, Kochmin Alexandr пишет:
> это ты бесплатный Qt юзаешь видимо?
Отож. :)
Он входит в большинство дистрибутивов.
На нём основан KDE, идущий по умолчанию в OpenSUSE, Fedora, Kubuntu, и
многих других сборках.
А в случае использования других DE, например GNOME или XFCE, GPL-ный Qt
поставится по зависимостям ежели установишь использующую его прогу.
Так что чтобы использовать коммерческий Qt в linux-ах придётся линковать
статиком, или заниматься каким другим извращением. :)

К тому же сейчас нет различия в кодовой базе между коммерческим, GPL-ным
и LGPL-ным вариантами.

Описаная трабла характерна именно для Ubuntu и производных, т. к. если
верить changelog-у в исходном Debian-овском пакете libqt4-sql-ibase
собирается. А в Ubuntu его отдельным местом отключают...

Причём ежели скачать исходники Qt и включить его обратно, то всё
собирается «на ура».
-- 
Александр Замараев



Re: Ubuntu и QIBASE - драйвер Firebird для Qt

2011-11-07 Пенетрантность Kochmin Alexandr

это ты бесплатный Qt юзаешь видимо?

07.11.2011 18:04, Tonal wrote:

Обнаружил тут неприятную вещь: драйвер QIBASE отключен при стандартной
сборке пакета.
Соответственно загрузить его из стандартного репозитория нельзя,
приходится пересобирать. А это, понятно, дополнительные напряги при
деплое... :(

Пакет должен называться libqt4-sql-ibase_4.7.4-0ubuntu8_i386.deb, но он
тупо отрублен в конфигах qt4-x11-4.x.x
Начиная с 4.4.0

Можа кто знает, можно ли на это повлиять?




Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-07 Пенетрантность Arioch
В письме от Fri, 04 Nov 2011 13:14:10 +0400, Dmitry Yemanov  
 сообщал:


А при arithmetic error что выводить? Движок понятия не имеет на этот  
момент, с какими строками/столбцами он работает. Код выполнения операций  
контекстно отвязан от выборки данных, ему все равно с чем работать на  
входе.



Ну как-то он привязан же ? ведь результаты кладутся куда надо ?
В случае ошибки вероятно исключение всплывает наверх и проплывает через  
код, который знает из каких строк он исходные значения взял.


--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-04 Пенетрантность Dmitry Yemanov

04.11.2011 1:22, Arioch пишет:


А с какими данными это произошло?
В какой строке в каком столбце какой таблицы ???


Ну и запросы у вас (с)


а план запроса можно построить по BLR ?


Конечно. Но причем тут план?


select * from VIEW_VECTOR_COSINES

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
Floating-point divide by zero. The code attempted to divide a
floating-point value by zero.


PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS))

План любопытный - показываются вьюхи, а не таблицы - но при этом
показывают PK от таблицЫ, а не от вьюх.


Показывается как имя вьюхи (VECTOR_COSINES) так и имя/алиас таблицы 
внутри вьюхи (Q).



Но зато есть статистика - а в статистике уже показаны не вьюхи, а
таблицы!!!


Причем тут статистика?


Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то
там, не помню уже), движок же может
для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы,
и для этих полей прочитать и сообщить значения ?


Какие именно значения сообщить? Ну при нарушении PK/UK теоретически 
возможно сообщить значение ключа-дубликата. А при arithmetic error что 
выводить? Движок понятия не имеет на этот момент, с какими 
строками/столбцами он работает. Код выполнения операций контекстно 
отвязан от выборки данных, ему все равно с чем работать на входе.



--
Дмитрий Еманов



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-03 Пенетрантность Arioch
В письме от Thu, 03 Nov 2011 22:22:43 +0400, Dmitry Yemanov  
 сообщал:


ФБ всегда сообщает о контексте ошибки (строка/столбец), если это  
произошло в процедуре. Если это не так - в трекер.


Ну сообщает.

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
Floating-point divide by zero.  The code attempted to divide a  
floating-point value by zero.

At procedure 'DO_CALCULATIONS' line: 13, col: 2.



А с какими данными это произошло?
В какой строке в каком столбце какой таблицы ???


будущем. Для нормальной диагностики нужен исходный код проблемного  
места. Из дерева выполнения (или даже BLR) реконструировать его - мягко


а план запроса можно построить по BLR ?




вот я соотв. кусок из процедуры забиваю напрямую:

select * from VIEW_VECTOR_COSINES

Arithmetic overflow or division by zero has occurred.
arithmetic exception, numeric overflow, or string truncation.
Floating-point divide by zero.  The code attempted to divide a  
floating-point value by zero.



PLAN JOIN (VECTOR_COSINES P NATURAL, VECTOR_COSINES Q INDEX (PK_VECTORS))

План любопытный - показываются вьюхи, а не таблицы - но при этом  
показывают PK от таблицЫ, а не от вьюх.




Более сложный запрос:
 merge into metrics m
   using vector_angles_deg v on m.idx=v.metrics_idx
   when matched then update set m.turn = v.angle;

Sorry, plan is unavailable for this statement...

Ну ладно, хемуль с ним с планом, хотя раньше был, кажется.
Но зато есть статистика - а в статистике уже показаны не вьюхи, а  
таблицы!!!



Так вот, зная таблицы и зная внутрение id каждой строки (RDB$ что-то там,  
не помню уже), движок же может
для каждой таблицы выбрать поля, входящие в PK или уникакльные индексы, и  
для этих полей прочитать и сообщить значения ?


В итоге это помогло бы точно определить на какие данных запрос сломался.
И столбец, и строки


Operations

Read   : 0
Writes : 0
Fetches: 51
Marks  : 3


Enchanced Info:
+--+---+---+-+-+-+-+--+--+--+
|Table Name|  Records  |  Indexed  | Non-Indexed | Updates  
| Deletes | Inserts | Backouts |  Purges  | Expunges |
|  |   Total   |   reads   |reads|  
| | |  |  |  |

+--+---+---+-+-+-+-+--+--+--+
|   METRICS| 0 | 1 |   0 |   1  
|   0 |   0 |0 |0 |0 |
|   VECTORS| 0 | 1 |   2 |   0  
|   0 |   0 |0 |0 |0 |

+--+---+---+-+-+-+-+--+--+--+



--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-03 Пенетрантность Dmitry Yemanov
ФБ всегда сообщает о контексте ошибки (строка/столбец), если это 
произошло в процедуре. Если это не так - в трекер.


Но при этом не сообщается, где именно в отдельном PSQL-запросе произошла 
ошибка. И я сильно не уверен, что такого стоит ожидать в ближайшем 
будущем. Для нормальной диагностики нужен исходный код проблемного 
места. Из дерева выполнения (или даже BLR) реконструировать его - мягко 
говоря непросто. А хранить debug info в разрезе синтаксических 
конструкций вместо текущих line-column - я вообще не уверен, что это 
правильный подход.


Так что пока придется мириться с тем, что есть.


--
Дмитрий Еманов



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-03 Пенетрантность Arioch
В письме от Wed, 02 Nov 2011 23:03:07 +0400, Алексей Вишняков  
 сообщал:



Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :)


предложат - пройду

но тут есть минимум два девела, кто инoгда может сразу влёт сказать "фигня  
вопрос" или "нет и не надейтесь, это только кажется легко"


иногда полезно обсудить и до трекера. мой первый пост в этой ветке это  
доказывает :-)


--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-02 Пенетрантность Алексей Вишняков
Щас вам с таким предложением посоветуют пройти в трекер. И будут правы :)

С уважением,
Алексей Вишняков

02.11.2011, в 23:00, Arioch  написал(а):

> В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov
>  сообщал:
>
>> 22.10.2011 9:21, Arioch пишет:
>> >
>> > Хорошая штука UPDATE с JOIN'ом :-)
>>
>> Чем MERGE не устроил?
>
>
> Вот
> Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и
> деление на ноль. В одной строке из множества.
>
> И все это внутри процедуры, хотя это и не так важно.
>
>
> Недостаток в том, что сообщив про деление на ноль, FB это просто
> констатирует, не сообщая где.
>
> Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов
> объединяются ещё две таблицы.
> Во всех таблицах есть PK, а в одной ещё и UNIQE индекс.
>
> Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в
> каком месте - было бы проще искать.
> Проанализировать таблицы, входящие в запрос, какие у них есть уникальные
> или PK-шные индексы, и добавить к сообщению об ошибке что-то типа
>
> "Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = "abc"));
> Table2(PK(Field1=2)); Table2(PK(Field1�)); Table3(PK(Field1=0));"
>
>
> --
> Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/
>


Re: Развлекаясь с заменой переменыз и массивов на FB. "update нa стероидах" - ах если бы... :-)

2011-11-02 Пенетрантность Arioch
В письме от Sat, 22 Oct 2011 13:33:46 +0400, Dmitry Yemanov  
 сообщал:



22.10.2011 9:21, Arioch пишет:
 >
 > Хорошая штука UPDATE с JOIN'ом :-)

Чем MERGE не устроил?



Вот
Нарвался в данных на совпадение двух точек подряд. Отсюда нуевая длина и  
деление на ноль. В одной строке из множества.


И все это внутри процедуры, хотя это и не так важно.


Недостаток в том, что сообщив про деление на ноль, FB это просто  
констатирует, не сообщая где.


Между тем, объединяетсЯ таблица и вьюха, в которую в несколько шагов  
объединяются ещё две таблицы.

Во всех таблицах есть PK, а в одной ещё и UNIQE индекс.

Если бы FB нарвавшись на жесткую ошибку типа деления на ноль, сообщил бы в  
каком месте - было бы проще искать.
Проанализировать таблицы, входящие в запрос, какие у них есть уникальные  
или PK-шные индексы, и добавить к сообщению об ошибке что-то типа


"Occured at: Table1(PK(field1=1; field2=2); Unique(field3 = "abc"));  
Table2(PK(Field1=2)); Table2(PK(Field1=-2)); Table3(PK(Field1=0));"



--
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/



Re: buffer overflow detected при вызове udf в isql

2011-10-28 Пенетрантность Vladimir
Коннект локальный.
Была ошибка в UDF.

Re: buffer overflow detected при вызове udf в isql

2011-10-28 Пенетрантность Vladimir
>
> Переполнение буффера, с 99.99% вероятностью проблема в UDF.
>

Действительно, отыскал ошибку.
Большое спасибо.

  1   2   3   4   5   6   7   8   9   10   >