Добрый день всем!

Для нового проекта решил освоить FB. Вопросы настройки сервера решились быстро (debian8), код пишу на чистом С в аналогичной среде на debian. Пакеты содержащие все необходимое (на тему ibase.h и libfbclient.so) проинсталил.


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

Роюсь вот в примерах.. Не прошу решить задчу) прошу подскажите с общим курсом.

Был у меня проектик, на чистом С. Мне так надо. Люблю этот язык, и кодить на нем люблю.. и быстродействие фантастическое.
В том проекте я слепил взаимодействие с MySQL. Вот что мне нравилось, так это простота несмотря на "низкоуровневость".

Сначала делаю SELECT, потом:
res = mysql_store_result(mysql);
numrows = mysql_num_rows(res);
numfields = mysql_num_fields(res);

И уже все понятно: сколько строк.. полей, и мне СЛАВА БОГУ ничего явно не требовалось указывать, выделять память вручную.
Разворачивай себе.. пока не упрешься в конец цикла по numrows или numfields, а память выделяется автоматом сколько надо при выполнении запроса.

Ну типа:
printf("%s" , sqlrow[n]); - и всего делов, грубо говоря. Ну, по задаче..

В Firebird мы полезли ради раздаваемых по клиентским приложениям сигналам по установке триггеров.
Моя часть на том же С. Т.к - быстродействие, сооружаем hi-load.

То что я туплю пока.. это абсолютно точно. Несколько дней потуплю еще. Но подскажите прямо - это я туплю, или написание С-кода на API напоминает сборку на ассемблере?? Я уже в паре мест нашел требование вручную указать размер массива, т.е его надо сначала спросить у базы, т.к я не знаю заранее и знать не хочу) размерность таблицы. Ну точнее хочу, но абсолютно не хочу переписывать в 100 местах потом код при модификации самой таблицы..

Ну или.. опять таки я возможно туплю но в найденном экземпле присутствует предварительное выделение памяти под данные, напр.
sqlda->sqlvar[2].sqldata = (char *) phone_ext;
и потом еще вручную нуль-терминировать конец строки:
phone_ext[sqlda->sqlvar[2].sqllen] = '\0';

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

Так!

Вас понял. Вот из того же экземпла:

while ((fetch_stat = isc_dsql_fetch(status, &stmt, 1, sqlda)) == 0)

//тут куча printf по этой строке

isc_dsql_fetch - извлекает одну строку. Так ведь? Вероятно так же как аналогичные *fetch* в MySQL.

Ранее я делаю
sqlda = (XSQLDA *) malloc(XSQLDA_LENGTH(3)); - в рассчете допустим, что я точно знаю что хочу получить 3 поля.

Но вот чего я не могу знать в общем случае в принципе, так это сколько будет строк.
Более того, 2 последовательных одинаковых SELECTa могут вернуть разное количкство строк, т.к HI LOAD. (реально у меня 2-15 транзакций в секунду).

В каком месте во всей этой системе запросов происходит выделение фактического объема памяти под результат запроса?
Допустим 818 строк. или 1000.
В момент isc_dsql_execute ?

>>во имя "не знаю заранее и знать не хочу".
Согласен с Вами, это несколько эмоционально написал.

>>Нормальные люди не выделяют память под весь result set
А я думал.. под это надо представлять с каким ОЗУ имеешь дело и использовать если что опцию LIMIT в запросе.
Конечно ПО тестируется на реальном железе.

>>Результат получается и обрабатывается построчно.
Не понял.
Т.е при каждом isc_dsql_fetch запрос к базе?

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

Далее. SELECT в данных примерах делается в обертке транзакции.
Результат атомарен пока я не закрою транзакцию?

Получается, память так-таки выделяется, но на сервере??

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

>>Зачем выделять память под 1000 записей, если одновременно идет работа только с одной?
Да ХЗ если честно.. привык мыслить в таком контексте. Надо отправить в аппарат 1000 идентов - извлек 1000 и пулеметной очередью выпустил по сети. А действительно нефиг в память копировать.