Хочу найти лучший вариант для работы вот с какими запросами...

Для начала немного истории: Специфика базы такова, что ежедневно закачивается таблица (больше 600 000 записей) на базе которой потом формируется куча всяких отчетов (ну и просто ее изучают, фильтруют, сортируют и все такое).
Так вот, проблема в следующем: запросы сложные и хотелось бы их с оптимизировать (и по скорости и способу хранения и использованию). Идеальным вариантом я конечно вижу хранения запросов в виде постоянных скомпилированных/оптимизированных Queries в базе. Достоинства:
1. запрос уже с оптимизирован и работает быстрее
2. в сложных запросах, эти сохраненые запросы вызываются из других.

Недостатки:
1. Всего лишь один. Имя таблицы как параметр не передашь и потому если таблицы имеют разные название (но и при этом абсолют. одинаковую структуру), то нифига не сделаешь.

То бишь, вопрос. Как лучше хранить/использовать запросы, если меняется имя таблицы (а структура ее постоянна)?

Как варианты:
1. генерить строку SQL - это всем понятно, недостатки известны, вообщем именно от этого и хотелось бы уйти.
2. менять имя таблицы на время запуска запроса. Опасно и малоприемливо (скоко всяких нехороших глюков можно породить)

P.S. или может я зря так геммороюсь и есть какой-нибудь станд. способ передачи в запрос в качестве параметра имя таблицы?, а я тут фигней всякой страдаю...

<I>3. Вместо обращения к таблице использовать сохраненный запрос select * from Таблица. И править его. И таблицы целы, и запрос только один на каждую табличку надо править.</I>

Остро, позарубежному (с) "Две башни снесло"

А этот запрос соответственно править через DAO, типа dbs.QueryDefs("ля-ля").SQL="select * from " & ИмяТаблицы

2Shark: Одну не заведешь... :( Каждый день новая приходит, а пихать в одну тоже не вариант, потому как объем сильно растет, и притом старые так и так удаляют, а иногда надо наоборот именно старую из архива достать и с нее пару очетов сварганить.

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

Varan: как я уже говорил, пузо треснет все в базу пихать, да и не надо это по большому счету. А объем.... это всего лишь баланс банка на конец рабочего дня... денюжжжжжки

БИС то конечно на AS-400 пашет :)

Имеются виды полный список счетов по балансовым позициям и работать приходится именно с основной таблицей, агригированныъ будет стокоже скоко и запросов (ну ладно, чуть меньше), но в общем все равно, в основом от большой основной таблицы никуда не денешься.

А как вы смотрите на вариант со связанной таблицей? (сам никогда так не пробовал, как хоть по ощущениям, какие плюсы, минусы?)

о Varan как завелся... :)

Access все-таки настольная база данных и до Банковских Информационных Систем ей далеко, у них задачи разные. Там мягко говоря маштабы разные и требования к надежности. Такие системы вообще НЕ для людей делаются, в отличии от Access... ;)

Break, break по углам, иначе я щас позову судью... :)

Давайте не будем отходить от первоначальной темы. Все мы тут хорошо знаем что из себя представляет Access, и в чем ее прелести и недостатки, и раз мы тут обсуждаем проблемы и нюансы использования этой самой Access, то я вообще не понимаю зачем начинать выяснять отношения по поводу нее... :(

2incold: переход на SQL запланирован, но пока токо в будущем, сначала она должна показать себе так сказать на месте.
(да и честно говоря даже на SQL я бы не рискнул туда пихать все в одну таблицу: 1день - 600 000, месяц - 15 мил., при том что 95 не пок ане нужны, а понадобиться например какой-нибудь позапозапрошлый месяц и то, ну не считая конечно сегодняшнего дня)