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

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

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

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

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

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

• 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, и ничего больше.