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.х ?
В
Вариант 3. Пытаюсь перегрузить операторы new и delete.
Попробуй в этом варианте сделать операторы инлайновыми или разместить их
в неименованном пространстве имён.
Т. е. скрыть от линкера.
Пробовал объявить свои перегруженные операторы как inline - все равно
в udf управление на них не
Vladimir ...
Похоже, линкер/загрузчик где-то путается с разрешением символов и вместо
rtl-ных new/delete подставляет какие-то левые.
Тут немного непонятно.
Если в моей udf используются new/delete от firebird, то почему они
приводят к ошибке?
Может быть, дело в другом?
Например, такая
Ок, пакуй БД и выкладывай куда-нить для ознакомления.
Если там ценные данные или их просто много, можно дропнуть не
нужные таблицы и выложить бекап.
ftp://gs.selfip.biz
user: temp
passw: temp
там архив с бэкапом. при разбэкапе понадобится УДФ-ка
Забавно:
При создании индекса оно валится вот на этих двух строках:
BANKKEY BANKCODE BANKMFO SWIFT
BANKBRANCH
148517044 749 153001749null
150695489 749 153001749null
null
Т.е.
29.11.2011 16:54, Yurij пишет:
Забавно:
При создании индекса оно валится вот на этих двух строках:
BANKKEY BANKCODE BANKMFO SWIFT BANKBRANCH
148517044 749 153001749 null
150695489 749 153001749 null null
Т.е. создание индексов не различает пустую строку и NULL в BANKBRANCH, а
group by -
Проблема в том, что по умолчанию линкер gcc экспортирует все ф-ции.
Соответственно, UDF цепляет delete движка (embedded коннект), или isql.
Движок в 2.5 вроде как уже поправили на этот счёт, но утилиты по прежнему
всё выставляют наружу.
Но тогда ведь и new бы цеплялась?
Или в чем-то
7 matches
Mail list logo
