Очень надо сохранить в таблицу (новую) записи UNION-запроса. Оптимально конечно было бы сразу задать в нем "INTO Table1", но так ведь INTO не работает же с UNION, а выдает мне результирующий набор записей доступный только для чтения... я в печали...остается что-ли только ручками создавать новую таблицу и сохранять в нее полученный от запроса recordset..??? (кстати может у кого уже есть универс. процедурка, которая это делает?)

Даа, до такого я не додумался, большой сэнкс...

Вспомнил... Access номинально же не позволяет разместить SELECT в инструкции FROM, т.е. - "SELECT * FROM (SELECT * FROM Table1)". Тут где-то уже обсуждался такой трабл и кто-то рассказал о недокументированной возможности Access, чтобы прошел такой запрос, необходимо добавить точку после скобок: "SELECT * FROM (SELECT * FROM Table1). WHERE и т.д.".
Так вот я об этом вспомнил только тогда когда запустил свой код, а он не заработал и я полез в конструктор запросов посмотреть что там навоялось. Код был такой:


Последний запрос (qryF101_3) не выполнился, но, как видно по коду, я по совету Саныча присваивал SQL инструкции запросам напрямую через свойство: dbs.QueryDefs("qryF101_3").SQL и мне стало интересно че там Access присвоил, я ожидал там увидеть свою строку, но когда открыл конструктор запросов (в режиме SQL), то увидел что Access мой запросик переделал по своему разумению...

Вот это то и есть самое интересное!!! Запрос мой не выполнился всего лишь из-за ошибки в запросе qryF101_1, после ее исправления все пошло, но посмотрите как мой запрос qryF101_3 переделал Access, чтобы он запустился:


Вернее конечно он сразу не запустился, но после того как уберете это мусор - ]. AS [%$##@_Alias] на что-нибудь другое, хоть так - ]. AS [ddd];, то все заработает.
Обратите внимание, что кроме незабвенной точки после скобок(п.1), сами скобки необходимо сделать квадратные(п.2) и обязательно добавить после точки(п.3) AS [ля-ля]. Без любого из этих 3 пунктов запрос не выполнится, это справедливо для Access2002, для других не знаю.

Вообщем, прикольно что таким образом удалось узнать некоторые недокументированные возможности Access SQL, надеюсь что и Вам рассказал что-то новое и полезное...

Думаю неплохо бы внести указанные дополнения по вложенным селектам в пост: недокументированные фичи - /topic/47491\r
\r
пусть наши гуру рассмотрят этот вопрос и в принципе я думаю из него уже можно делать FAQ "недокументированные фичи " - пусть лучше под таким заголовком болтается, так его легче и приятнее искать..

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

Причем несмотря на заявление, у меня Access2002 работает только с этой жесткой порнографией, а ни как иначе.

Есть предположение, что access все такие запросы к выше указанной жесткой порнаграфии приводит...

К вопросу об оптимизации:

В результате тестов определили, что:
1. запуск двух запросов на создания двух таблиц и и спользование их же потом в третьем запросе, выполняется гораздо быстрее чем
2. изменение двух сохраненных запросов (dbs.QueryDefs("qryF101_1").SQL = srtSQL1) и указания потом их в третьем запросе

Усредненные результаты замеров по вариантов (в миллисек.):
1. 5530
2. 10914

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

В продолжении к вопросу о вложенных селектов в FROM.


Вот такой еще маленький нюансик, такой запрос не пойдет:

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

Да это в моем есть... просто когда обсуждали эту недокументированную возможность этот маленький нюансик тогда не прозвучал, а я вот сейчас в него уперся\r
\r
надо дополнить что-ли наш FAQ по недокумент. возможностям, тот топик вроде пока до FAQ не дошел: /topic/47491