20 Knox [2008-10-04 19:08:00]
В некоторых запросах Microsoft Access появляется следующее сообщение: Операция должна использовать обновляемый запрос. (Ошибка 3073). Я работаю над этим, используя временные таблицы, но мне интересно, есть ли лучший способ. Все задействованные таблицы имеют первичный ключ. Здесь код:
21 ответ
22 Решение David-W-Fenton [2008-10-05 00:12:00]
Так как Jet 4, все запросы, которые имеют соединение с оператором SQL, который суммирует данные, будут невосстанавливаемыми. Вы не используете JOIN, но предложение WHERE в точности эквивалентно соединению, и, таким образом, оптимизатор запросов Jet обрабатывает его так же, как и к соединению.
Я боюсь, что вам не повезло без временной таблицы, хотя, возможно, кто-то с большим знанием Jet SQL, чем я могу придумать обходной путь.
BTW, возможно, он был обновляем в Jet 3.5 (Access 97), так как многие запросы были обновляемыми, а затем обновлялись до Jet 4.
7 Ray Brack [2012-05-10 03:07:00]
У меня была аналогичная проблема, когда следующие запросы не работали;
Однако использование DLookup разрешило проблему;
Это решение изначально было предложено в qaru.site/questions/252794/.
4 Glenn M [2008-10-08 00:02:00]
Задача defintely относится к использованию (в данном случае) функции max(). Любая функция агрегации, используемая во время соединения (например, для получения значения max или min или avg из объединенной таблицы), вызывает ошибку. То же самое относится к использованию подзапросов вместо объединений (как в исходном коде).
Это невероятно раздражает (и необоснованно!), поскольку это достаточно распространенная вещь, которую нужно делать. Мне также пришлось использовать временные таблицы, чтобы обойти его (вытащите агрегированное значение в таблицу temp с помощью инструкции insert, затем присоединитесь к этой таблице с вашим обновлением, а затем опустите таблицу temp).
В коде отсутствует ошибка. Но ошибка вызывается из-за следующей причины.
Предположим, что вы сохранили базу данных (файл MS-Access) в папке только для чтения, а при запуске приложения соединение не открывается полностью. Следовательно, измените разрешение файла/его разрешение на папку, например, в C:Program files , все большинство файлов c cd установлены только для чтения, поэтому изменение этого разрешения разрешает эту проблему.
Я знаю, что мой ответ за 7 лет, но здесь мое предложение в любом случае:
Когда Access жалуется на запрос UPDATE, который включает JOIN, просто сохраните запрос, а свойство RecordsetType установлено в Dynaset (Inconsistent Updates) .
Это иногда позволяет UPDATE работать.
Я бы попытался создать запрос UPDATE в Access. У меня был запрос UPDATE, который я написал себе как
Запрос дал мне ту ошибку, которую вы видите. Однако это работало на моем SQL Server, но, как и в предыдущих ответах, синтаксис Access UPDATE не является стандартным синтаксисом. Однако, когда я перестроил его с помощью мастера запросов Access (он использовал синтаксис JOIN), он работал нормально. Обычно я просто делаю запрос UPDATE транзитной для использования синтаксиса не JET, но одна из таблиц, с которыми я соединялась, была локальной таблицей Access.
Это происходит, когда нет ключа UNIQUE MS-ACCESS для обновляемой таблицы (таблиц). (Независимо от схемы SQL).
При создании ссылок MS-Access для SQL-таблиц вам предлагается указать индекс (ключ) во время ссылки. Если это сделано неправильно или вообще нет, запрос к связанной таблице не обновляется
При связывании таблиц SQL в Access MAKE УВЕРЕНА, что, когда Access запрашивает у вас индекс (ключ), вы используете именно то, что использует SQL, чтобы избежать проблем, хотя указание любого уникального ключа – это все, что необходимо для обновления таблицы.
Если вы не были человеком, который первоначально связал таблицу, удалите связанную таблицу с MS-ACCESS (ссылка удаляется только) и повторно привяжите ее, указав ключ правильно, и все будет работать правильно.
1 nspire [2014-08-04 11:29:00]
Мину не удалось выполнить простую инструкцию INSERT. Исправлено при запуске приложения с доступом "Запуск от имени администратора" .
MS Access – объединение таблиц в запрос на обновление. как сделать его обновляемым
- Откройте запрос в режиме просмотра
- Нажмите один раз на ссылку b/w tables/view
- В окне "Свойства" измените значение "уникальные записи" на "да"
- Сохраните запрос как запрос обновления и запустите его.
1 mark [2010-09-17 18:44:00]
(Немного поздно вечеринке. )
В прошлом я столкнулся с тремя способами:
- Ссылка на текстовое поле в открытой форме
- DSum
- DLookup
1 marcnz [2012-07-09 07:39:00]
У меня была такая же проблема.
Мое решение состоит в том, чтобы сначала создать таблицу из неперерабатываемого запроса, а затем выполнить обновление из таблицы в таблицу и работать.
0 leeand00 [2012-08-15 17:30:00]
Когда я получил эту ошибку, возможно, из-за неправильного синтаксиса UPDATE, но после того, как я исправил запрос на обновление, я снова получил ту же ошибку. поэтому я пошел в ODBC Data Source Administrator и обнаружил, что мое соединение был доступен только для чтения. После того, как я установил соединение для чтения-записи и повторного подключения, он работал нормально.
0 [2008-12-02 03:53:00]
Я продолжал получать ту же ошибку, пока я не установил в поле соединения уникальный индекс в обеих таблицах соединений. Только тогда запрос стал обновляемым.
0 htm11h [2013-01-17 21:48:00]
Здесь есть другой сценарий. Файл, который был проверен с помощью Visual Source Safe, для тех, кто все еще использует его, который не был указан "Writeablity", либо в опции "Вид", либо "Выход", также получит это сообщение об ошибке.
Решение состоит в том, чтобы повторно загрузить файл из Source Safe и применить параметр Writeability.
проверьте свою БД (разрешение базы данных) и дайте полное разрешение
Перейдите в папку DB- > щелкните правой кнопкой мыши свойства- > security- > edit- > , чтобы получить полный контроль и меню "Пуск" → run- > type "uac" уменьшают (если он высокий)
В сущности, хотя ваш SQL выглядит вполне разумным, Jet никогда не поддерживал синтаксис SQL стандарта для UPDATE . Вместо этого он использует свой собственный проприетарный синтаксис (отличный от синтаксиса UPDATE SQL Server), который очень ограничен. Часто, обходные пути "Операция должна использовать обновляемый запрос" очень болезненны. Серьезно подумайте о переходе на более надежный SQL-продукт.
Более подробную информацию о ваших конкретных проблемах и некоторых возможных обходных решениях см. в Обновить запрос на основе итоговых запросов результатов.
Я продолжал получать ту же ошибку, но все SQL-запросы выполняются в Access очень хорошо.
и когда я изменил разрешение AccessFile.
Я предоставляю ‘ Сетевое обслуживание‘ полное управление правами доступа, эта учетная запись, если для IIS
Сегодня в моем MS-Access 2003 с таблицей ODBC, указывающей на SQL Server 2000 с паролем sa, я получил ту же ошибку.
Я определил первичный ключ в таблице в базе данных SQL Server, и проблема исчезла.
0 RSmith [2013-03-12 19:26:00]
Вы всегда можете написать код в VBA, который обновляется аналогичным образом. У меня тоже была эта проблема, и в моем обходном пути был сделан выборный запрос со всеми объединениями, в котором были все данные, которые я искал, чтобы обновлять их, делая этот набор записей и повторяя запрос обновления повторно как запрос на обновление только таблица обновлений, только поиск критериев, которые вы ищете
Я делаю это только до 60 записей в день, делая это до нескольких тысяч, может занять гораздо больше времени, поскольку запрос выполняется от начала до конца несколько раз, вместо того, чтобы просто выбирать общую группу и вносить изменения. Возможно, вам понадобится "вокруг кавычек для tableID, так как это строка, но я уверен, что это то, что сработало для меня".
Чтобы еще раз ответить на то, о чем говорил DRUA в его/ее ответе.
Я разрабатываю свои базы данных в Access 2007. Мои пользователи используют время выполнения Access 2007. У них есть права на чтение в папку database_Front (front end) и права на чтение/запись в папку database_Back.
При развертывании новой базы данных пользователь не выполнил полные инструкции по копированию интерфейса на свой компьютер и вместо этого создал ярлык. Запуск Front-End через ярлык создаст условие, при котором запрос не будет обновляться из-за ограничений записи файла.
Копирование интерфейса в папку документов разрешает проблему.
Да, это усложняет ситуацию, когда пользователям приходится получать обновленную версию интерфейса, но, по крайней мере, запрос работает без необходимости использовать временные таблицы и т.д.
0 Sue White [2016-11-30 03:17:00]
Ответ, высказанный iDevlop, работал у меня. Обратите внимание, что я не смог найти свойство RecordsetType в своем запросе обновления. Тем не менее, я смог найти это свойство, изменив свой запрос на запрос select, установив это свойство как iDevlop, а затем изменив свой запрос на запрос обновления. Это сработало, нет необходимости в таблице temp.
Мне бы хотелось, чтобы это было просто комментарием к тому, что отправил iDevlop, чтобы оно вытекало из его решения, но у меня недостаточно высокий балл.
в некоторых запросах Microsoft Access я получаю следующее сообщение: операция должна использовать обновляемый запрос. (3073 ошибка). Я работаю над этим, используя временные таблицы, но мне интересно, есть ли лучший способ. Все таблицы имеют первичный ключ. Вот код:
21 ответов
начиная с Jet 4, все запросы, имеющие оператор join to a SQL, который суммирует данные, будут не обновляемыми. Вы не используете соединение, но предложение WHERE точно эквивалентно соединению, и, таким образом, оптимизатор запросов Jet обрабатывает его так же, как и соединение.
боюсь, вам не повезло без временной таблицы, хотя, возможно, кто-то с большими знаниями Jet SQL, чем я могу придумать обходной путь.
кстати, возможно, он был обновляем в Jet 3.5 (доступ 97), в целом многие запросы были обновлены, а затем стали не обновляемыми при обновлении до Jet 4.
у меня была аналогичная проблема, когда следующие запросы не работали;
однако использование DLookup решило проблему;
проблема определенно связана с использованием (в этом случае) функции max (). Любая функция агрегирования, используемая во время соединения (например, для извлечения значения max или min или avg из присоединенной таблицы), вызовет ошибку. То же самое относится и к использованию подзапросов вместо соединений (как в исходном коде).
Это невероятно раздражает (и неоправданно!) поскольку это достаточно распространенная вещь, чтобы хотеть сделать. Мне также пришлось использовать временные таблицы, чтобы обойти его (вытащить агрегированное значение в временную таблицу с инструкцией insert, затем присоединитесь к этой таблице с обновлением, затем удалите временную таблицу).
в коде нет ошибки. Но ошибка возникает по следующей причине.
предположим, что вы храните базу данных (файл MS-Access)в папке только для чтения, при запуске приложения соединение не полностью открыто. Следовательно, измените разрешение файла / его содержащее разрешение папки, как в C:Program files все большинство файлов дисков c были установлены только для чтения таким образом, изменение этого разрешения решает эту проблему.
Я знаю, что мой ответ опоздал на 7 лет, но вот мое предложение в любом случае:
когда Access жалуется на запрос обновления, который включает соединение, просто сохраните запрос с RecordsetType свойство имеет значение Dynaset (Inconsistent Updates) .
иногда это позволяет обновлению работать.
Я бы попытался создать запрос обновления в Access. У меня был запрос на обновление, который я написал сам, как
запрос дал мне эту ошибку вы видите. Это работало на моем SQL Server, но, как и предыдущие ответы, синтаксис обновления доступа не является стандартным синтаксисом. Однако, когда я перестроил его с помощью мастера запросов Access (он использовал синтаксис JOIN), он работал нормально. Обычно я бы просто сделал запрос обновления passthrough для использования синтаксиса non-JET, но одна из таблиц, в которой я был соединение с было локальной таблицей доступа.
это происходит, когда нет уникального ключа MS-ACCESS для обновляемых таблиц. (Независимо от схемы SQL).
при создании ссылок MS-Access на таблицы SQL вам предлагается указать индекс (ключ) во время ссылки. Если это сделано неправильно или вообще не сделано, запрос к связанной таблице не подлежит обновлению
при связывании таблиц SQL в Access убедитесь, что при запросе доступа для индекса (ключа) вы используете именно то, что SQL использует, чтобы избежать проблема(ы), хотя указание любого уникального ключа-это все, что нужно для обновления таблицы.
Если вы не были человеком, который первоначально связал таблицу, удалите связанную таблицу из MS-ACCESS (ссылка только удаляется) и повторно свяжите ее, указав ключ правильно, и все будет работать правильно.
(немного опоздал на вечеринку. )
три способа, которыми я обошел эту проблему в прошлом:
- ссылка на текстовое поле в открытой форме
- DSum
- функции dlookup
У меня была та же проблема.
мое решение состоит в том, чтобы сначала создать таблицу из не обновляемого запроса, а затем выполнить обновление из таблицы в таблицу, и это работает.
Mine не удалось с помощью простого оператора INSERT. Исправлено путем запуска приложения с ‘Запуск от имени администратора’ открыть.
MS Access-объединение таблиц в запросе обновления. как сделать его обновляемым
- открыть запрос в режиме конструктора
- нажмите один раз на ссылку ч/б таблиц/вид
- в окне" Свойства "измените значение" уникальные записи "на"да"
- сохраните запрос как запрос обновления и запустите его.
Я продолжал получать ту же ошибку, пока не сделал соединительное поле уникальным индексом в обеих соединительных таблицах. Только тогда запрос стал обновляемым.
по сути, хотя ваш SQL выглядит вполне разумно, Jet никогда не поддерживал стандартный синтаксис SQL для UPDATE . Вместо этого он использует свой собственный синтаксис (отличный от собственного UPDATE синтаксис), которая составляет очень общества. Часто единственные обходные пути "операция должна использовать обновляемый запрос" очень болезненны. Серьезно подумайте о переходе на более способный продукт SQL.
для некоторых больше деталей о ваших специфических проблемах и некоторых возможные обходные пути, см. обновление запроса на основе итогов запроса не удается.
Я продолжал получать ту же ошибку, но все SQLs выполняются в Access очень хорошо.
и когда я изменил разрешение из AccessFile.
Я даю ‘Сетевая Служба‘ учетная запись полный контроль разрешение, эта учетная запись, если для IIS
когда я получил эту ошибку, это могло быть из-за неправильного синтаксиса обновления, но после того, как я исправил запрос обновления, я снова получил ту же ошибку. поэтому я пошел в ODBC Data Source Administrator и обнаружил, что мое соединение доступно только для чтения. После того, как я сделал соединение read-write и re-connected, он работал нормально.
сегодня в моем MS-Access 2003 с таблицей ODBC, указывающей на SQL Server 2000 с паролем sa, дал мне ту же ошибку.
Я определил первичный ключ таблицы в базе данных SQL Server и проблема исчезла.
здесь есть другой сценарий, который будет применяться. Файл, который был извлечен из Visual Source Safe, для тех, кто все еще использует его, который не был задан "Writeablity", либо в опции View или Check Out, также получит это сообщение об ошибке.
решение, чтобы повторно получить файл из источника безопасный и применить настройку Writeability.
для дальнейшего ответа на то, что Друа упомянул в своем ответе.
Я разрабатываю базы данных в Access 2007. Мои пользователи используют среду выполнения access 2007. У них есть разрешения на чтение папки database_Front (front end) и разрешения на чтение/запись в папку database_Back.
при развертывании новой базы данных пользователь не следовал полным инструкциям по копированию передней части на свой компьютер и вместо этого создал ярлык. Запуск Front-end через ярлык создаст условие, при котором запрос не будет обновляться из-за ограничений записи файла.
копирование передней части в папку "Документы" решает проблему.
Да, это усложняет ситуацию, когда пользователи должны получить обновленную версию интерфейса, но, по крайней мере, запрос работает без необходимости прибегать к временным таблицам и тому подобное.
проверьте свою БД (разрешение базы данных) и дайте полное разрешение
перейдите в папку DB – > щелкните правой кнопкой мыши свойства – >безопасность – > изменить – > дать полный контроль & Меню Пуск – >Выполнить – > тип " uac " сделать его вниз (если он высокий)
вы всегда можете написать код в VBA, который обновляется аналогичным образом. У меня тоже была эта проблема, и мой обходной путь делал запрос select со всеми соединениями, у которых были все данные, которые я искал, чтобы иметь возможность обновлять, делая это набором записей и выполняя запрос update повторно как запрос update только таблицы обновления, только поиск критериев, которые вы ищете
Я делаю это только около 60 записей в день, делая это в несколько тысяч может занять много дольше, поскольку запрос выполняется от начала до конца несколько раз, вместо того, чтобы просто выбирать общую группу и вносить изменения. Возможно, Вам понадобится ” вокруг кавычек для tableID, так как это строка, но я уверен, что это сработало для меня.
ответ, данный выше iDevlop, работал для меня. Обратите внимание, что мне не удалось найти свойство RecordsetType в моем запросе обновления. Однако мне удалось найти это свойство, изменив запрос на запрос select, установив это свойство, как отметил iDevlop, а затем изменив запрос на запрос обновления. Это сработало, не нужно временной таблицы.
Я хотел бы, чтобы это был просто комментарий к тому, что опубликовал iDevlop, чтобы он вытекал из его решения, но у меня нет максимума достаточно очков.
На некоторых запросов Microsoft Access, я получаю следующее сообщение: В операции должен использоваться обновляемый запрос. (Ошибка 3073). Я работаю вокруг него, используя временные таблицы, но мне интересно, если есть лучший способ. Все таблицы, участвующие имеют первичный ключ. Вот код:
Так как Jet 4, все вопросы, которые имеют присоединиться к SQL заявления, который суммирует данные будут не обновляемые. Вы не используете JOIN, но условие WHERE точно эквивалентно присоединиться, и, таким образом, оптимизатор запросов Jet обрабатывает это так же, как он лечит присоединиться.
Я боюсь, что вы не повезло без временной таблицы, хотя, возможно, кто-то с большим Jet SQL знаний, чем я могу придумать обходной путь.
Кстати, это могло бы быть обновляемым в Jet 3.5 (Access 97), в целом много запросов было обновляемым то, что стало не обновляемой при переходе на Jet 4.
У меня была аналогичная проблема, когда следующие запросы не будет работать;
Однако при использовании DLookup решить эту проблему;
Там нет ошибки в коде. Но ошибка возникает из-за следующей причине.
предположим , что вы хранятся в базе данных (файл MS-Access) в папке только для чтения, во время работы приложения соединение не принудительно полностью открыт. Следовательно , изменить / ее содержащее разрешение папки на разрешении файла , как и в C:Program files все большинстве всех файлов с диском было установлено только для чтения поэтому изменение этого разрешения решает эту проблему.
Проблема Defintely относится к применению (в данном случае) функции (макс). Любая функция агрегации используется во время объединения (например, чтобы получить макс или мин или среднее значение из присоединяемой таблицы) вызовет ошибку. И то же самое относится и к использованию подзапросов вместо объединения (как и в исходном коде).
Это невероятно раздражает (и неоправданной!), Так как это довольно распространенная вещь, чтобы хотеть сделать. Я также должен был использовать временные таблицы, чтобы вокруг него (тянуть агрегированные значения в временную таблицу с помощью оператора вставки, а затем присоединиться к этой таблице с обновлением, то уронить временную таблицу).
Я знаю, что мой ответ 7 лет поздно, но вот мое предложение все равно:
Когда Access жалуется на запрос UPDATE , который включает в себя JOIN, просто сохранить запрос, с RecordsetType собственностью установлен Dynaset (Inconsistent Updates) .
Это иногда позволяет UPDATE работать.
Это происходит, когда не уникальный MS-ключ доступа к таблице (ах) обновляется. (Вне зависимости от схемы SQL).
При создании MS-Access Ссылки на таблицы SQL, вам будет предложено указать индекс (ключ) во время связи. Если это будет сделано неправильно, или вообще, запрос против связанной таблицы не является обновляемым
При компоновке таблиц SQL в Access УБЕДИТЕСЬ, что когда доступ запрашивает индекс (ключ), который вы используете именно то, что SQL использует, чтобы избежать проблем (ы), хотя указания каких-либо уникального ключа все Access необходимо обновить таблицу.
Если вы не тот человек, который первоначально связана таблица, удалить связанную таблицу из MS-ACCESS (ссылка только будет удалена) и повторно ссылка он указав ключ правильно и все будет работать правильно.
Я хотел бы попробовать строить запрос UPDATE в Access. У меня был UPDATE запрос, который я написал сам, как
Запрос дал мне эту ошибку вы видите. Это работало на моем SQL Server, хотя, но так же, как ранее ответов отмечено, синтаксис доступа UPDATE не стандартный синтаксис. Однако, когда я восстановил его с помощью мастера запросов доступа (он используется синтаксис JOIN) он работал отлично. Обычно я просто сделать UPDATE запроса транзитным использовать синтаксис не-JET, но один из столов я вступающие с был местный столом Access.
MS Access – объединение таблиц в запросе обновления . как сделать его обновляемым
- Открыть запрос в режиме конструктора
- Нажмите один раз на линии ч / б таблиц / просмотр
- В окне «Свойства» измените значение для «уникальных записей» на «да»
- Сохранить запрос как запрос обновления и запустить его.
Шахта не удалась с простым INSERT IGNORE заявления. Фиксированный, запустив приложение с «Запуск от имени администратора» доступа.
Я была такая же проблема.
Мое решение является первым создать таблицу из запроса, не обновляемый, а затем выполнить обновление от стола к столу, и она работает.
(Немного опоздал на вечеринку . )
Три способа я получил вокруг этой проблемы в прошлом, являются:
- Ссылка на текстовое поле на открытой форме
- DSum
- DLookup
Ответ дается выше, iDevlop работал для меня. Обратите внимание, что я не смог найти свойство RecordsetType в моем запросе обновления. Тем не менее, я был в состоянии найти эту собственность, изменив свой запрос запроса на выборку, установив, что свойство, как указано iDevlop, а затем изменить мой запрос запроса на обновление. Это не сработало, нет необходимости в временную таблицу.
Я бы хотел, чтобы это просто комментарий к тому, что iDevlop размещены так, чтобы она текла из его решения, но у меня нет достаточно высокого балла.
проверить DB (разрешение базы данных) и дать полное разрешение
Перейти к БД папке-> правой кнопкой мыши свойства-> безопасности-> Edit-> дать полный контроль & Start меню -> run-> введите «UAC» сделать его вниз (если он высокий)
Для дальнейшего ответа, что DRUA упоминается в его / ее ответа .
Я развиваю свои базы данных в Access 2007. Мои пользователи используют Access 2007 выполнения. Они разрешения на чтение папки database_Front (передний конец), и права на чтение / запись в папку database_Back.
В выкатывает новую базу данных, пользователь не соблюдал полные инструкций копирования переднего конца своего компьютер, а вместо этого создал ярлык. Запуск Front-конца через ярлык создаст условия, когда запрос не является обновляемым из-за ограничения файловой записи.
Копирование переднего конца их папка документов решает эту проблему.
Да, это усложняет ситуацию, когда пользователи должны получить обновленную версию переднего конца, но, по крайней мере, запрос работает без необходимости прибегать к временным таблицам и тому подобным.
Вы всегда можете написать код в VBA, который обновляет аналогичным образом. Я тоже был эта проблема, и мой обходной путь делает запрос на выборке, со всеми стыками, которые были все данные, которые я искал, чтобы иметь возможность обновлять, делая что записи и выполнение запроса обновления повторно в качестве обновления запроса только таблица обновления, только поиск критериев, которые вы ищете
Я делаю это только около 60 записей в день, делая это до нескольких тысяч могут занять гораздо больше времени, так как запрос выполняется от начала до конца несколько раз, вместо того, чтобы просто выбрать общую группу и внесение изменений. Вам может понадобиться «» вокруг котировок TABLEID, так как это строка, но я уверен, что это то, что работает для меня.
Существует еще один сценарий здесь будет применяться. Файл, который был извлечен из Visual Source Safe, для тех, кто все еще использует его, что не был дан «Writeablity», либо в опции View или Check Out, также Получать это сообщение об ошибке.
Решение заключается в повторном приобретении файл из Source Safe и применить настройку Writeability.
