from:"�� "


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: Путь к bin


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


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 Пенетрантность Yurij

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

Re: Путь к bin


Yurij пишет:

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


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


--
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ь 
без переноса строк?

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

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

Наткнулся на такую глючу.
В запросе ниже, выдаётся разные результаты при закомментированном и
раскомментированном group by, хотя вроде бы должны быть одинаковые.

with recursive
SYM as (
  select sr1.ID, sr1.PARENT_ID
  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

Или меня опять подводит мой «здравый смысл»?
Пример возник из попытки написать проверку некоторого условия которое
зависит от родителей.
Т. е. SYM предполагался довольно сложным - вычисляющим данные для этого
условия.

ОС Kubuntu 11.10 i386
Сервер SS 2.5.0.26074 из стандартных реп.

Табличка:
CREATE TABLE SYMPTOMS (
  ID D_ID,
  PARENT_ID D_ID_OR_NULL,
  -- отгрызено полей
  CONSTRAINT PK_SYMPTOMS PRIMARY KEY (ID),
  CONSTRAINT FK_SYMP2SYM_ID FOREIGN KEY (SYM_ID) REFERENCES SYMPTOMS (ID)
);

Данные:
INSERT INTO SYMPTOMS (ID, PARENT_ID) VALUES ('450797', '450773');
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');

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

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

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


Tonal ...

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


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

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

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

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 Пенетрантность 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 Пенетрантность Dmitry Yemanov


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


Похоже.


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



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

delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_IDCURRENT_CONNECTION

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

Установлена ОС Mandriva 2009 x64, 9Гб оперативки, винты 160Гб.
До этого стоял *FirebirdSS-2.5.0.25946-ReleaseCandidate3.amd64* конструкция
отваливает все залипшие коннекты из текущей БД, а далее и в цикле из всех
архивов. Работало безупречно:

  in AUTONOMOUS TRANSACTION
  do delete from MON$ATTACHMENTS where
MON$ATTACHMENTS.MON$ATTACHMENT_IDCURRENT_CONNECTION;
  --
  for
select a_path from DYN_PATH_NAME_ARCH(null, 199901, 201110)
  into :PATH
  do begin
IN AUTONOMOUS TRANSACTION
DO BEGIN
  EXECUTE STATEMENT ('delete from MON$ATTACHMENTS'
||' where MON$ATTACHMENTS.MON$ATTACHMENT_IDCURRENT_CONNECTION')
ON EXTERNAL :PATH AS USER 'SYSDBA' PASSWORD :PASS;
END
  end

После установки *FirebirdSS-2.5.1.26351-0.amd64*, такая конструкция валит
сервер наглухо. Приложения выполняющее этот запрос висит не реагируя. Не
помогает service firebird restart, а также stop/start. Зависшего процесса не
замечено. В логе firebird.log лишь несколько строк об ошибках с номерами и
стопа, запуска, перезапуска:
/   INET/inet_error: read errno = 104
/opt/firebird/bin/fbguard: /opt/firebird/bin/fbserver terminated 
abnormally
(-1)
/opt/firebird/bin/fbguard: guardian starting /opt/firebird/bin/fbserver
INET/inet_error: bind errno = 98
/opt/firebird/bin/fbguard: /opt/firebird/bin/fbserver terminated due to
startup error (2)
INET/inet_error: read errno = 9
INET/inet_error: read errno = 104
/, и т.п.
Сама ось не висит. Только после перезагрузки оси роботоспособность
восстанавливается. Как вы понимаете это крайняя мера и не допустима. Это уже
второй раз так случается и прослеживается закономерность.
Вопрос к разработчикам что происходит. Если конструкция с
MON$ATTACHMENTS.MON$ATTACHMENT_ID больше не работает, то подскажите как
теперь без последствий отключать непослушные коннекты?

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

Re: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_IDCURRENT_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: delete from MON$ATTACHMENTS where MON$ATTACHMENTS.MON$ATTACHMENT_IDCURRENT_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_IDCURRENT_CONNECTION

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

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

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

Такой скипт после установки новой версии 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_IDCURRENT_CONNECTION

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


reshetnyakvkt ...


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


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

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

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-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 Пенетрантность Vlad Khorsun


Vladimir ...


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



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


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

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

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

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



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



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

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

http://gsbelarus.com/gs/modules.php?name=Downloadsd_op=getitlid=63

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

http://gsbelarus.com/gs/modules.php?name=Downloadsd_op=getitlid=95

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

GD_X_BANK_BANKCODE

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

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

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

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

BANKKEY BANKCODE BANKMFO  SWIFT
BANKBRANCH
148517044 749  153001749null
150695489 749  153001749null   
null

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

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

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


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

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

BANKKEY BANKCODE BANKMFO SWIFT BANKBRANCH
148517044 749 153001749 null
150695489 749 153001749 null null

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


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


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

Re: new / delete в UDF

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

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

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

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

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

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


A K ...

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


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


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


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


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

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


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


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

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


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

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

Re: new / delete в UDF


Vladimir ...

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


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


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


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

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

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

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


A K ...

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

--
Влад

Re: new / delete в UDF

2011-11-23 Пенетрантность Vadim Mescheryakov


Vladimir ...

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

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

offtopic - прога по недвижимости

2011-11-28 Пенетрантность Sergey Mereutsa

Привет!

Народ, если кто занимается прогами, связанными с недвижимостью
(продажа/покупка/агенты) - свистните мне в мыло на serj собака dqteam
ком - может что-нибудь вкусное всем перепадёт.

-- 
Best regards,
 Sergey  mailto:gebele...@gmail.com

Re: new / delete в UDF

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

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

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

Re: new / delete в UDF

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


Vladimir ...

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


   Да

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

Re: new / delete в UDF

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

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

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

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

Проверить существование учетной записи пользователя

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

На радостях заменил в проекте весь код создания/удаления учетных записей 
пользователей с сервисов на команды CREATE USER/DROP USER.


Но, вот незадача, как сделать проверку существования учетной записи
без обращения к сервисам?

Пока, ничего умнее

alter user yyy set middlename ''

и отлова ошибки с GDSCode = 336723990 на ум не приходит.

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

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


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

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

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


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


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

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

Андрей

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

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: Проблема с уникальным индексом на 2.5.1

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




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


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

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

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


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

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

Re: new / delete в UDF

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



On Nov 18, 11:08 am, Khorsun Vlad hv...@optima.com.ua wrote:
 Vladimir ...

  !

  Linux UDF, gcc,
  :

   long* aTestItem = new long;
   delete aTestItem;

  Segmentation fault delete.

     ,
 .so ӣ .

 --

Re: new / delete в UDF

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

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

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

new / delete в UDF

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

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

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

long* aTestItem = new long;
delete aTestItem;

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

В Windows все проходит без ошибок.

Если библиотеку использовать не в UDF, а вызывать из простого
тестового приложения, все проходит без ошибок и в Linux.

Есть ли возможность использовать в UDF в Linux операторы new / delete?

Речь идет не о возвращаемом результате, все происходит внутри UDF.

Если заменить new / delete на malloc / free, ошибки не возникает.
Но в UDF требуется работать с классами.
Как вариант, рассматриваю возможность размещать экземпляры классов по
malloc с последующим явным вызовом конструкторов.
Но используемая система классов достаточно громоздкая.
Кроме того, хотелось бы минимизировать отличия между Windows и Linux
версиями.

Поэтому вопрос для меня очень насущный.

Есть ли возможность использовать в UDF в Linux операторы new / delete?

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

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


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

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

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


Alexey Popov ...

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


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

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

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

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


Vlad Khorsun wrote:


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


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

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


Alexey Popov wrote:

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

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


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

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: Тозмоза простейших запросов


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 ...

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

Ну и что ?

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

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

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

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

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

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

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

Khorsun Vlad wrote:

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

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

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

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

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

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

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

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

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

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

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

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

В письме от Fri, 11 Nov 2011 15:30:35 +0400, Alexey Popov  
a...@novgorod.net сообщал:


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


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


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

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

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

В письме от Thu, 20 Oct 2011 19:30:32 +0400, Vsevolod  
iuaa...@gmail.com сообщал:


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

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


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

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

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