Запрос по набору записей
Ответы 2
Не получится - придется выполнять их как отдельные команды
Предположительно, вы объявили rs как набор записей, поэтому вы можете использовать его для возврата результатов оператора SELECT.
Я бы использовал команду SQL для выполнения второго оператора.
Набор записей можно определить только с помощью одного оператора SELECT (хотя, конечно, вы можете объединить несколько выборок, если они имеют одинаковое количество столбцов).
Любое действие SQL (INSERT, UPDATE, DELETE) не может быть выполнено с набором записей, кроме использования метода .Execute.
Если вы используете ADO, .Execute также можно использовать для SELECT (он возвращает строки), но собственный уровень интерфейса данных Jet, DAO, не может - .Execute работает только для запросов действий. Мне это кажется разумным, но лично мне ADO всегда казалась пустой тратой времени.
Кроме того, Jet (механизм db, используемый Access по умолчанию) не может выполнять несколько операторов SQL одновременно, как это могут сделать многие серверные механизмы db. Это не такое уж большое ограничение, как может показаться тем, кто привык к пакетным операциям SQL, - просто другое.
«Jet ... не может выполнять несколько операторов SQL одновременно ... Это не такое уж большое ограничение» - это ОГРОМНОЕ ограничение! Это заставляет человека писать несколько хранимых процедур и доверять клиентскому коду для их вызова в правильном порядке или - глоток! - напишите свою логику база данных на стороне клиента.
Э-э, Jet не может выполнять несколько операторов, но нельзя ли их объединить в сквозной запрос? Это явным образом поставит всю обработку на стороне сервера и, как мне кажется, устранило бы ваше возражение. Он по-прежнему не будет работать с серверной частью Jet, но, ну, сервер здесь не задействован.
«Это все равно не сработает с бэкендом Jet» - вот мое возражение! например вы не можете написать даже простой upsert (en.wikipedia.org/wiki/Upsert): вместо этого вы должны написать процедуру INSERT и процедуру UPDATE и доверять клиентскому коду, чтобы либо выбрать правильный, либо запустить (и отработать отказ) оба.
Тогда не используйте JET в качестве серверной части. Ооо.
Так что, если мне нужна процедура «upsert», мне следует избегать Jet, верно? Ну, тогда это почти все приложения, ориентированные на данные, которые я когда-либо писал :)
Если вам нужна хранимая процедура, вы вообще не собираетесь использовать Jet. Итак, я действительно не понимаю, в чем ваша проблема.
Моя «проблема» (как вы выразились) в том, что я привык как к Jet, так и к ядрам баз данных, которые могут выполнять несколько операторов SQL в одной хранимой процедуре, и тот факт, что они являются взаимоисключающими, является причиной, по которой я теперь избегаю Jet. Но я бы назвал это исправлением вашего искажения, а не проблемой :)
Кстати, я много лет использовал синтаксис CREATE PROCEDURE DDL в Jet. Я использую термин «сохраненная процедура Jet» для обозначения объекта базы данных, созданного с помощью CREATE PROCEDURE. Замените свой собственный термин по своему усмотрению, но Jet и сохраненные процедуры не являются взаимоисключающими.
Это одна из тех прекрасных несоответствий, которые возникают при использовании ADO, общего уровня абстракции для управления Jet вместо собственных интерфейсов. Создаваемая вами ПРОЦЕДУРА совсем не похожа на то, что есть в серверном ядре базы данных.
CREATE PROCEDURE - это собственный синтаксис Jet DDL (Jet 4.0 и ACE), не имеющий ничего общего с ADO. Проблема в том, что ты использует уровень абстракции: различие между PROCEDURE и VIEW теряется для вас, потому что MS Access объединяет их вместе как общий объект Query. Точно так же DAO видит только QueryDef.
Да, он был вставлен в Jet DDL для согласованности с ADO. То, что вы получаете, используя результат в Jet (или Access), совсем не похоже на процедуру в базе данных сервера.
Возможность отличить SQL VIEW от других видов исполняемого хранимого SQL является более богатой моделью, чем наличие всего лишь одного объекта Query. Это хорошая вещь. Какая разница, была ли «согласованность с ADO» движущей силой таких изменений ?!
Есть ли другой способ, который я имею в виду, кроме разделения их