Добрых времен, специалисты! Нужен совет по логике? (пните куда рыть)

Дано: Delphi 2007, FireBird 2.1 (+EhLib, +Fib, + сторонние компоненты)

Все было разработано, все работало как надо, но в один миг СИЛЬНО увеличилась нагрузка (в сотни раз, фирма развивается и на такие нагрузки, я просто не расчитывал)

Логика значит сейчас такая:
Коннект к сторонней базе. Получаю в клиента ~3000 записи. Беру первую запись.
Делаю Select к своей базе проверяю по 3 значениям (индексы, план все вроде в порядке, запрос летит шустро, НО ИХ МНОГО). Если есть такая запись - забыли. Иначе полез по таблицам, добавляю в справочники инфу. Добавляю новую запись. Записал. Следующую запись... и по кругу, и так до конца... (ну там за одно еще справочники проверяются, но это не критично.) Естественно на сервере вскипает процессор под 100% пиком.

Все хорошо пока сторонних баз было 3-5. Но когда их стало под 200. Из каждой выдернуть все записи и на каждую запись кинуть Select в мою базу. Тут процессор чето приуныл. Тяну данные из 10 баз одновременно. Процессор в шоке. Полный цикл проходит за 40 минут, без ошибок и т.п.. Но процессор в это время "жужжит" и не дает работать бухгалтерии, от слова совсем.
Такой импорт делается 4-5 раз в день, сами понимаете, бухгалтерии времени на работу не остается.

Лирика кончилась. Проект буду переделывать.

Теперь вопрос: Вот чтоб не убивать сервер тупыми запросами select, можно ли как-то выдернуть кусок таблицы "от даты, до даты(которые известны при старте импорта" в память клиента и уже у него проводить сверку по конкретным параметрам?
Куда копать MemtableEh?

Желательно у клиента в памяти создать "нечто" к чему можно обращаться Query, т.е. виртуальную (БД) табличку. Куда рыть?

(Если вариант совсем глупый, пинайте ногами. За сумбурность извините, не спал, проект горит. Побеспокоил, потому, что времени на переработку НЕТ. Все перечитать не могу... пните что читать, куда думать? )

Симонов Денисdgdog,

сначала объясни откуда взялись 200 БД и почему их нельзя слить в одну.

1. БД разные. 1С. Самописные Firebird. Текстовые файлы банковских выписок.
Вот так вот, а сливаются в одну УЖЕ в моей базе. Собственно она для этого и нужна.

2. Почему приходится перепроверять фигову тучу записей? Потому, что какой-нибудь бухгалтер нафигачит проводок задним числом... и пипец... какой-то оператор, перебьет к чертям вчерашнюю проводку. Поэтому каждую запись получил и лезу в свою базу проверять есть такая или подобная? (если есть подобная, то еще алгоритм "а не измененная ли это?")

Ну суть вопроса хочу уйти от сотен тысяч запросов к серверу. Получить кусок таблицы на клиента, там разобраться и уже с чистой совестью писать в базу.

rdb_devdgdog, что мешает импортировать записи только от штампа времени последнего импорта?

Старые записи могут добавиться, измениться (бухгалтерии косячят. 1С откатывается в БэкАп...) Из вводных данных имею только конкретные даты "от... и до..." Остальное я и разбираю. Но слишком много обращений к бд. Они плевые, но их много. Мнеб вот это "От... и до..." как-то на клиента утянуть и там уже крутить - вертеть и к базе лишний раз не лезть.

Симонов ДенисArioch,

я так понял что он сначала текстовые файлы в отдельные БД на firebird сливает, а потом из этих БД в центральную ещё.

Нет. Цепляюсь например (клиентом) к 10 1С ком соединением. Получаю из каждой кусок данных от ДАТЫ до ДАТЫ. Потом клиент берет каждую запись и лезет в мою базу с проверкой есть такая или нет? Если есть - забыли. Если нет - добавить. (Это грубо там логика в клиенте сверка всяких параметров полученной записи и записей в БД... я такую логику в самом Firebird не осилю.)

(Базы разные от 1С и до папки с файлами платежных поручейний из банков.)

Пусть на каждой из "200 БД" запускается служба подготовки к выгрузке.

(базы разные от 1С, Firebird, ... и до простых текстовых файлов экспорта из клиентбанков)

Симонов ДенисArioch,

с трудом представляю сервак который потянет 200 БД одновременно. Ну 10 ещё куда ни шло.

Сервак тянет 1 БД Firebird Остальные базы лежат где-как и в локальной сети и на удаленках... я из них только данные тяну на клиента, а уже потом фигачу в БД

(плохо я задачу объясняю, завтра высплюсь мож легче будет )