iBase.ru Forum

FB 1.5 SS, SQL 3
Такая проблема. Есть таблица ~600000 записей. Надо выгрузить ее в DBF. В IBE запускаю экспорт дроходит до 399999 (иногда меньше) и валится с "Out of memory". Ваяю в дельфе экспортер: IBQuery + select = DBF - та же картина.

В чем может быть причина?

И еще. Как можно для таких случаев выбирать на клиента только одну запись, т.е. выбрал запись, обработал, удалил, взял следующую и т.д.?

Или TIBSQL вместо TIBQuery или Unidirectional := true;

TIBSQL

не поможет, я делаю экспорт в DBF

Unidirectional - вот это похоже и есть

ну так КТО валится по out of memory. IBSQL не буферизирует считываемые записи.
короче,
www.ibase.ru/devinfo/impexp.htm

самое интересное, что эту статью несколько раз перечитывал, но почему-то утвердился во мнении, что TIBSQL - только для быстрой вставки записей, не подумал, что им можно и выбирать на клиента.

лоханулся, что и говорить...

Dynamic писал(а): лоханулся, что и говорить...

Дело в том, что я тоже тут похожую штику делаю. Тока наоборот - импорт из DBF. Тут дело обстоит посложнее.
Объясняю: в DBF-файлах используются свои уникальные поля (допустим CODE), а у меня в FB, естественно, свои. Конечно, в моих таблицах имеется соответствующее поле (CODE). А проблема в том, что при переборе записей в DBF-файле мне необходимо найти соответствующий ID в моей таблице. А для этого я использую хранимые процедуры. Короче... все так долго работает. Таблица в 400000 записей импортируется примерно за 8 часов. Может кто поделится опытом по решению такой задачки?

400000 записей за 8 часов - примерно 13 записей в секунду - неприятно медленно
приведи свои структуры пожалуйста
у меня на заливке данных с поисками и проверками получается 200-500 записей в секунду, попробую подсказать

DBF-файле мне необходимо найти соответствующий ID в моей таблице. А для этого я использую хранимые процедуры. Короче... все так долго работает.

www.ibase.ru/devinfo/testiu.htm

Dynamic писал(а):самое интересное, что эту статью несколько раз перечитывал, но почему-то утвердился во мнении, что TIBSQL - только для быстрой вставки записей, не подумал, что им можно и выбирать на клиента.

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

Dimitry Sibiryakov писал(а):TIBSQL - наиболее универсальный и вто же время легкий компонент. В-общем-то я уже давно ничего кроме его не использую.

а для отображения данных что (если не секрет, конечно)? Обычные контролы?

Dynamic писал(а):а для отображения данных что (если не секрет, конечно)? Обычные контролы?

Да. TStringGrid, TListView. Быстро и красиво. Самое сложное было сломать пользователей чтобы они не хотели видеть полный список.
Для редактирования - тоже соответствующие TEdit, TMemo, TDateTimePicker и т.д.

я тоже к этому подхожу, но это :

Dimitry Sibiryakov писал(а): Самое сложное было сломать пользователей чтобы они не хотели видеть полный список.

- самое сложное....
Вобщем-то давно хотел спросить об этом, но вот попутно получилось

aaa3d писал(а):400000 записей за 8 часов - примерно 13 записей в секунду - неприятно медленно
приведи свои структуры пожалуйста
у меня на заливке данных с поисками и проверками получается 200-500 записей в секунду, попробую подсказать

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

kdv писал(а):www.ibase.ru/devinfo/testiu.htm

Этот тест неполный, и учитывает только вставку процедурную. Реально же наиболее быстр может быть алгоритм вставки с клиента (!) insert и update с использованием "баланса" вставок/обновлений.
Поясню идею. Начинаем с insert, если эксепшн, увеличиваем счётчик ошибок, делаем update. Если ошибок накопилось, скажем, 5 подряд, то первое действие для следующей записи не insert, а update, и соответственно, проверяем RowsAffected на 0. Удачные вставки (обновления) изменяют баланс в свою сторону. Соотношение 1:5 наиболее подходяще (по моим тестам, с клиента update+проверка+insert занимает в 5 раз больше времени, чем insert+эксепшн+update, как это ни странно).

Данный механизм работает на любом % наложения быстрее процедур, вплоть до 15-20%, в моей конкретной базе, по крайней мере. В DBF порядка 130000 записей каждый раз.

Dimitry Sibiryakov писал(а):TStringGrid, TListView. Быстро и красиво. Самое сложное было сломать пользователей чтобы они не хотели видеть полный список. Для редактирования - тоже соответствующие TEdit, TMemo, TDateTimePicker и т.д.

Регресс однако. Мучились Борланды, TDataSet, TDataSource и прочие DB-Aware компоненты придумывали... А в итоге все в корзину . Имхо, современные компьютеры позволяют не смотреть на потерю пары тысяч тактов...

Кроме тактов есть еще и другие невосполнимые ресурсы. ОЗУ и пропускная способность сети, например. Кроме того это в компонентах такты теряются тысячами, а на сервере - уже миллионами и миллиардами. И так для каждого пользователя. В результате этот форум переполнен криками "отчего у меня так все тормозит?"...

Dimitry Sibiryakov писал(а):Кроме тактов есть еще и другие невосполнимые ресурсы. ОЗУ и пропускная способность сети, например.

Хорошо. Тогда чем отличается фетч записей с сервера SQL и DataSet'а? И там и там по сети будут переданы одни и те же данные. Это первое. Второе - поставить на сервер еще 128/256/512/1024 метров - не проблема. Зато всем будет проще жить (и программисту, и пользователю). Первому - за счет упрощения кодирования, простоте рефакторинга и прочего, вторым - за счет уменьшения глючности продукта и легкости его модификации по его просьбам.

Dimitry Sibiryakov писал(а):Кроме того это в компонентах такты теряются тысячами, а на сервере - уже миллионами и миллиардами. И так для каждого пользователя. В результате этот форум переполнен криками "отчего у меня так все тормозит?"...

Тормозит при причине криворукости программистов (95%) и админов (4%), а не из-за того, что теряются такты. А сколько тактов теряется в самом Firebird'е, никто не считал?

CyberMax писал(а):Тогда чем отличается фетч записей с сервера SQL и DataSet'а? И там и там по сети будут переданы одни и те же данные. Это первое. Второе - поставить на сервер еще 128/256/512/1024 метров - не проблема. Зато всем будет проще жить (и программисту, и пользователю).

Вот. А теперь внимательно перечитываем название темы и первый пост. У человека не хватает памяти под ненужное ему кэширование.

Dimitry Sibiryakov писал(а):А теперь внимательно перечитываем название темы и первый пост. У человека не хватает памяти под ненужное ему кэширование.

TIBQuery тут ни при чем. Извините за резкость, это криворукость программиста, который использует его для задач, для которых он не предназначен. Те самые 95%, о которых я писал...

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