"Kovalenko Dmitry" ...
...
> > Более того - ты можешь передавать разные статус-векторы в
> > каждую ф-цию АПИ.
>
> Если под "разными status-векторами"
> подразумеваются разные переменные, в
> которые будет сохранен status-вектор, то у
> меня они и так разные. Поскольку
> представляют собой локальные
> переменные, объявленные прямо перед
> вызовом API
Вполне разумный подход
> > Откуда библиотека должна знать, какой статус
> > ты сейчас собираешься интерпретировать ? Да и не заставляет тебя
> > никто пользоваться isc_interprete - можешь парсить его сам :)
>
> Я смотрел на эту главу в
> API-документации. Вопрос такой - кто
> выделил память под текстовый аргумент
> ошибки и когда она освободится?
См. ниже - fbclient. Память гарантировано действительна до следующего
вызова АПИ в этом коннекте. Некоторые ф-ции АПИ также не трогают эту память,
например isc_interprete :)
> Понимаю, что "возьми исходники и
> посмотри", но у меня духу не хватает :)
Привести пример, как парсить статус-вектор ? Хотя в IBX оно где-то
точно есть
> > Далее - правила игры таковы, что время жизни содержимого
> > статус-вектора, возвращённое тебе библиотекой, определяется
> > этой самой библиотекой. Вполне справедливо, имхо. И между
> > вызовами АПИ оно никуда не теряется.
>
> Как это никуда не теряется? Что, даже
> если я переподключусь к базе данных -
> все равно могу воспользоваться своим
> _специально_ сохраненным древним
> status-вектором?
Я же написал - "между вызовами АПИ оно никуда не теряется".
Если ты можешь переподключиться, не вызывая АПИ, то... мне тут
советовать нечего :) Ну и, если вектор не содержит строк, - то
таки можешь воспользоваться
> Или если этот текст будет динамически
> сгенерированным текстом исключения
> (слышал что такое толи уже есть, толи
> очень хотят). Такой текст тоже будет
> храниться до посинения?
Правила общие. Строки, связанные со статус-вектором, живут
в буфере под сетевой пакет. Буфер перезаписывается при приёме
следующего пакета, т.е. при (не каждом) вызовах АПИ. С embedded
чуть по-другому, т.к. нет сетевого обмена, но это правило тоже
должно быть в силе.
...
> <блокировка подключения>
> - вызов API
> - обработка ошибки
> <снятие блокировки>
>
> Меня всегда интересовал вопрос выноса
> обработки ошибки за пределы
> блокировки.
А что - есть с этим проблемы ? Какие ? Или у тебя во время
обработки ошибки другой поток может вызвать АПИ в этом же коннекте ?
Ещё - неужели обработка ошибки занимает так много времени,
что это влияет на длительность блокировки ?
> > У нас разные понятия о корректности :)
>
> Дык это. Для меня сервер/gds32 это черные
> ящики. Я их постигаю через созерцание.
> Кинешь камень - и смотришь на волны. А
Да уж, камней и волн мы сегодня наделали достаточно :)
> для тебя они всего лишь набор костей и
> мяса из набора "сделай своего
> франкенштейна":)))
От такая проза жизни :)
--
Хорсун Влад
