Чем делать импорт и экспорт данных в InterBase?

Это скорее не статья, а перечень средств для решения указанной задачи, вроде списка инструментария из downloads.

Собственно, тип импорта и экспорта данных бывает:

1. одноразовый, когда нужно перенести данные из одного проекта в другой,
2. редкий, когда задача переноса данных возникает от случая к случаю,
3. постоянный, когда импорт или экспорт данных является неотъемлемой составной частью проекта.

Соответственно, готовые инструменты импорта-экспорта годятся в основном для первых двух типов задачи, всевозможные драйверы – для второго и третьего, и в третьем случае, как правило, используется только код приложений, написанных самостоятельно.

Итак, перечислим все возможные инструменты и способы именно в этом порядке:

• IBPump – позволяет переносить данные из источников ADO, BDE, ODBC в базы Interbase, а также переносить данные из одной базы Interbase в другую. Может сохранять конфигурацию для упрощения повторного переноса данных, отключать триггеры на время копирования данных, выполнять функции "утилиты командной строки" (silent mode) и др. Т. е., как видите, годится для всех трех случаев.
• BDE – возможно использовать для копирования данных посредством выполнения так называемых "гетерогенных запросов". В том числе содержит компонент TBatchMove, которым можно копировать данные даже в DesignTime, т. е. при разработке приложения. В силу на ограничение использования транзакций, а также из-за неполной поддержки 3-го диалекта баз Interbase годится для второго случая, и редко – для третьего.
• ODBC-драйверы. Можно получать или передавать данные используя MS Office, Access и другие офисные приложения. Второй и третий случай соответственно.
• драйверы OLE DB, в частности IBProvider. То же самое что и ODBC, только с полным контролем транзакций, управлением кэширования данных и т. п.
• External tables – для регулярного импорта и экспорта данных. Пример использования – тест скорости вставки/обновления данных. Недостатки – фиксированный размер строки, а значит невозможность передачи varchar, blob.
• TIBBatch и наследники от этого класса, IBSQL.PAS из IBX (и аналогичные классы в FIBPlus). Позволяют работать с данными фиксированного размера, с текстовыми файлами с разделителями (csv) и т. п. Подходит для всех случаев, потому что в самом простом случае код например для экспорта в csv-файл составляет всего 5-6 строк (примеры есть в хелпе – d7ibx.hlp/ibx.hlp и т. п.).
• IBExpert и IBEScript – позволяют копировать данные путем генерации скрипта. Например, для небольшой базы данных можно извлечь целиком метаданные и данные в виде команд insert.
• IB_SQL – использовать можно если эта утилита у вас под рукой, и вы регулярно ею пользуетесь. Механизм переноса (только между базами IB) – коннект к двум БД, в одной select, в другой insert.

Для компонент и драйверов необходимо отметить следующее: многие при первом подходе к "снаряду" в качестве источника экспортируемых/импортируемых данных используют TTable, TQuery, IBQuery, IBDataSet и подобные компоненты. Поскольку указанные компоненты кэшируют результат запроса в памяти, это приводит к исчерпанию памяти на машине, где находится копирующая данные программа, или к серьезному замедлению процесса копирования. Поэтому подобные компоненты ни в коем случае нельзя использовать для экспорта/импорта – вместо них надо использовать TIBSQL (IBX) или pFIBQuery (FIBPlus). Эти компоненты не имеют кэша и работают только с одной записью в памяти. Поэтому экспорт/импорт данных будет максимально эффективным.

По указанной причине не следует импортировать данные например в IBDataSet или TTable – при импорте каждой записи будет перевыполняться запрос, читающий данные (SelectSQL или автоматически генерируемый в TTable или "живом" TQuery select), а значит чем больше импортируется записей, тем медленнее с их количеством будет происходить импорт. При экспорте с использованием этих компонент работа будет происходить быстрее, но все равно считываемые для экспорта данные будут накапливаться в буфере компонента, что вызовет постоянный рост используемой приложением памяти (и опять же вызовет замедление экспорта вплоть до ошибки out of memory).

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