Ringkasan
Ini adalah bug yang diketahui disebabkan oleh pembaruan Office yang dirilis pada 12 November 2019. Bug ini mempengaruhi semua versi Access yang saat ini didukung oleh Microsoft (dari Access 2010 hingga 365).
bug ini telah diperbaiki.
- Jika Anda menggunakan versi Office C2R (Klik untuk Menjalankan), gunakan "Perbarui sekarang" :
- Access 2010 C2R: Diperbaiki dalam Build 7243.5000
- Access 2013 C2R: Diperbaiki dalam Build 5197.1000
- Akses 2016 C2R: Diperbaiki dalam Bangun 12130.20390
- Akses 2019 (v1910): Diperbaiki dalam Build 12130.20390
- Access 2019 (Volume License): Diperbaiki dalam Build 10353.20037
- Saluran Bulanan Office 365: Diperbaiki dalam Bangun 12130.20390
- Semi-Tahunan Office 365: Tetap dalam Bangun 11328.20480
- Office 365 Semi-Tahunan Diperpanjang: Tetap dalam Bangun 10730.20422
- Office 365 Ditargetkan Semi-Tahunan: Tetap dalam Bangun 11929.20494
- Jika Anda menggunakan versi MSI Office, instal pembaruan yang cocok dengan versi Office Anda. Semua tambalan ini telah dirilis pada Pembaruan Microsoft, jadi menginstal semua Pembaruan Windows yang tertunda harus cukup:
Contoh
Berikut adalah contoh repro minimal:
- Buat database Access baru.
- Buat tabel baru, kosong "Table1" dengan bidang ID default dan bidang Long Integer "myint".
Jalankan kode berikut di Jendela Langsung editor VBA:
CurrentDb.Execute "UPDATE Table1 SET myint = 1 WHERE myint = 1"
Hasil yang diharapkan : Pernyataan berhasil diselesaikan.
Hasil aktual dengan salah satu pembaruan kereta diinstal: Terjadi galat run-time 3340 ("Kueri 'rusak").
Tautan yang berhubungan:
90150000-006E-0409-0000-0000000FF1CE
... itu-0409-
, tidak-0407-
.-006E-0409-
juga. Kedua mesin memiliki Paket Layanan 1 untuk Microsoft Office 2013 (KB2850036) diinstal.{90140000-0011-0000-0000-0000000FF1CE}
dalam skrip kumpulan. Perhatikan{9014...
tidak{9114..}
Solusi paling sederhana
Untuk pengguna saya, menunggu hampir sebulan hingga 10 Desember untuk rilis perbaikan dari Microsoft bukanlah suatu pilihan. Juga tidak mencopot pembaruan Microsoft yang melanggar di beberapa stasiun kerja yang dikunci oleh pemerintah.
Saya perlu menerapkan solusi, tetapi saya tidak senang dengan apa yang disarankan Microsoft - membuat dan mengganti kueri untuk setiap tabel.
Solusinya adalah mengganti nama Tabel dengan
(SELECT * FROM Table)
kueri sederhana langsung diUPDATE
perintah. Ini tidak memerlukan membuat dan menyimpan satu ton permintaan tambahan, tabel, atau fungsi.CONTOH:
Sebelum:
Setelah:
Itu seharusnya lebih mudah diimplementasikan di beberapa basis data dan aplikasi (dan kemudian rollback).
sumber
Ini bukan masalah pembaruan Windows, tetapi masalah yang diperkenalkan dengan rilis Office Patch Selasa November. Perubahan untuk memperbaiki kerentanan keamanan menyebabkan beberapa permintaan yang sah dilaporkan korup. Karena perubahan itu merupakan perbaikan keamanan, ini memengaruhi SEMUA unit Office, termasuk 2010, 2013, 2016, 2019, dan O365.
Bug telah diperbaiki di semua saluran, tetapi waktu pengiriman akan tergantung pada saluran yang Anda gunakan.
Untuk membangun Lisensi Volume MSI 2010, 2013, dan 2016, dan saluran Semi-tahunan O365, perbaikannya akan berada di build Selasa Patch Desember, 10 Desember. Untuk O365, Saluran Bulanan, dan Orang Dalam, ini akan diperbaiki ketika garpu Oktober dirilis, saat ini direncanakan untuk 24 November.
Untuk saluran Semi-Tahunan, bug diperkenalkan pada 11328.20468, yang dirilis 12 November, tetapi tidak menyebar ke semua orang sekaligus. Jika bisa, Anda mungkin ingin menunda pembaruan hingga 10 Desember.
Masalah terjadi untuk pembaruan kueri terhadap satu tabel dengan kriteria yang ditentukan (jadi jenis kueri lainnya tidak boleh terpengaruh, maupun kueri yang memperbarui semua baris tabel, atau kueri yang memperbarui kumpulan hasil kueri lain). Karena itu, solusi paling sederhana dalam kebanyakan kasus adalah mengubah kueri pembaruan untuk memperbarui kueri lain yang memilih semuanya dari tabel, daripada memperbarui kueri secara langsung.
Yaitu, jika Anda memiliki pertanyaan seperti:
Lalu, buat kueri baru (Kueri1) yang didefinisikan sebagai:
dan perbarui kueri asli Anda ke:
Halaman resmi: Kesalahan akses: "Permintaan rusak"
sumber
Untuk menyelesaikan sementara masalah ini tergantung pada versi Access yang digunakan:
Access 2010 Menghapus pembaruan KB4484127
Access 2013 Menghapus instalan pembaruan KB4484119
Access 2016 Menghapus instalasi pembaruan KB4484113
Akses 2019 JIKA DIPERLUKAN (tbc). Turunkan Versi dari Versi 1808 (Build 10352.20042) ke Versi 1808 (Build 10351.20054)
Office 365 ProPlus Downgrade dari Versi 1910 (Build 12130.20344) ke versi sebelumnya, lihat https://support.microsoft.com/en-gb/help/2770432/ how-to-revert-to-an-versi-sebelumnya-office-2013-or-office-2016-clic
sumber
Kami dan klien kami telah berjuang dengan ini dua hari terakhir dan akhirnya menulis makalah untuk membahas masalah ini secara rinci bersama dengan beberapa solusi: http://fmsinc.com/MicrosoftAccess/Errors/query_is_corrupt/
Ini mencakup temuan kami yang memengaruhi solusi Access saat menjalankan kueri pembaruan pada tabel lokal, tabel Access tertaut, dan bahkan tabel SQL Server yang ditautkan.
Ini juga memengaruhi solusi non-Microsoft Access menggunakan Access Database Engine (ACE) untuk tersambung ke database Access menggunakan ADO. Itu termasuk aplikasi Visual Studio (WinForm), aplikasi VB6, dan bahkan situs web yang memperbarui akses database pada mesin yang tidak pernah memiliki akses atau kantor diinstal pada mereka.
Kecelakaan ini bahkan dapat memengaruhi aplikasi Microsoft yang menggunakan ACE seperti PowerBI, Power Query, SSMA, dll. (Tidak dikonfirmasi), dan tentu saja, program lain seperti Excel, PowerPoint atau Word menggunakan VBA untuk mengubah database Access.
Selain penghapusan yang jelas dari Pembaruan Keamanan yang menyinggung, kami juga menyertakan beberapa opsi ketika tidak mungkin untuk menghapus karena izin atau distribusi aplikasi Access ke pelanggan eksternal yang PC-nya berada di luar kendali Anda. Itu termasuk mengubah semua kueri Pembaruan dan mendistribusikan aplikasi Access menggunakan Access 2007 (ritel atau runtime) karena versi itu tidak terpengaruh oleh pembaruan keamanan.
sumber
Gunakan modul berikut untuk secara otomatis mengimplementasikan solusi yang disarankan Microsoft (menggunakan kueri alih-alih tabel). Sebagai tindakan pencegahan, buat cadangan database Anda terlebih dahulu.
Gunakan
AddWorkaroundForCorruptedQueryIssue()
untuk menambahkan solusi danRemoveWorkaroundForCorruptedQueryIssue()
untuk menghapusnya kapan saja.Anda dapat menemukan kode terbaru di repositori GitHub saya .
AddWorkaroundForCorruptedQueryIssue()
akan menambahkan akhiran_Table
ke semua tabel non-sistem, misalnya tabelIceCreams
akan diubah namanya menjadiIceCreams_Table
.Itu juga akan membuat kueri baru menggunakan nama tabel asli, yang akan memilih semua kolom dari tabel berganti nama. Dalam contoh kami, kueri akan diberi nama
IceCreams
dan akan menjalankan SQLselect * from [IceCreams_Table]
.RemoveWorkaroundForCorruptedQueryIssue()
melakukan tindakan sebaliknya.Saya menguji ini dengan semua jenis tabel, termasuk tabel non-MDB eksternal (seperti SQL Server). Namun perlu diketahui, bahwa menggunakan kueri alih-alih tabel dapat menyebabkan kueri yang tidak dioptimalkan dijalankan terhadap database backend dalam kasus tertentu, terutama jika kueri asli Anda yang menggunakan tabel berkualitas baik atau sangat kompleks.
(Dan tentu saja, tergantung pada gaya pengkodean Anda, juga dimungkinkan untuk memecah hal-hal dalam aplikasi Anda. Jadi setelah memverifikasi bahwa perbaikan umumnya bekerja untuk Anda, tidak pernah merupakan ide yang buruk untuk mengekspor semua objek Anda sebagai teks dan menggunakan beberapa pengganti mencari sihir untuk memastikan bahwa setiap kejadian penggunaan nama tabel akan dijalankan terhadap kueri dan bukan tabel.)
Dalam kasus saya, memperbaiki ini bekerja sebagian besar tanpa efek samping, aku hanya perlu secara manual mengubah nama
USysRibbons_Table
kembali keUSysRibbons
, karena saya tidak ditandai sebagai tabel sistem ketika saya buat di masa lalu.sumber
TableDef.Attributes
dan menyalinnya ke jawaban saya;) dan fungsi undo adalah ide yang bagus (tapi nama lama dan baru harus disimpan dalam sebuah tabel karena tergantung pada tidak ada tabel dengan akhiran sebelum nama diubah). Beberapa bagian lainnya rusak (mis. Tabel dapat diakhiri dengan akhiran atau nama baru sudah digunakan atauOn Error Resume Next
tanpa menangani kesalahan nanti). Apakah Anda tahu RubberduckVBA ? Addin ini dapat memeriksa kode Anda dan membuat saran yang bagus untuk perbaikan, di samping semua fitur lainnya.Bagi mereka yang ingin mengotomatiskan proses ini melalui PowerShell , berikut adalah beberapa tautan yang saya temukan yang mungkin membantu:
Deteksi dan Hapus Pembaruan yang Menyinggung
Ada skrip PowerShell yang tersedia di sini https://www.arcath.net/2017/09/office-update-remover yang mencari registri untuk pembaruan Office tertentu (disahkan sebagai nomor kb) dan menghapusnya menggunakan panggilan untuk
msiexec.exe
. Script ini mem-parsing kedua GUID dari kunci registri untuk membangun perintah untuk menghapus pembaruan yang sesuai.Satu perubahan yang saya sarankan akan menggunakan
/REBOOT=REALLYSUPPRESS
seperti yang dijelaskan dalam Cara menghapus KB4011626 dan pembaruan Office lainnya (Referensi tambahan: https://docs.microsoft.com/en-us/windows/win32/msi/uninstalling-patches ). Baris perintah yang Anda bangun terlihat seperti ini:Perintah untuk menjalankan skrip akan terlihat seperti ini:
Cegah Pembaruan Tidak Menginstal
Pendekatan yang disarankan di sini tampaknya menyembunyikan pembaruan . Jelas ini dapat dilakukan secara manual, tetapi ada beberapa skrip PowerShell yang dapat membantu dengan otomatisasi. Link ini: https://www.maketecheasier.com/hide-updates-in-windows-10/ menjelaskan proses secara rinci, tapi saya akan meringkas di sini.
Gunakan perintah berikut untuk menyembunyikan pembaruan berdasarkan nomor KB:
Hide-WUUpdate -KBArticleID KB4484127
Semoga ini bisa membantu orang lain di luar sana.
sumber
VBA-Script untuk MS-Workaround:
Disarankan untuk menghapus pembaruan kereta, jika mungkin (jika tidak coba kode saya), setidaknya untuk Versi MSI. Lihat jawaban https://stackoverflow.com/a/58833831/9439330 .
Untuk Versi CTR (Klik untuk Menjalankan), Anda harus menghapus semua Pembaruan November Kantor, apa yang dapat menyebabkan masalah keamanan serius (tidak yakin apakah ada perbaikan kritis yang akan dihapus).
Dari komentar @ Eric:
Table.Tablename
untuk mengikat formulir, mereka tidak terikat karena nama tabel sebelumnya sekarang menjadi nama-permintaan !.OpenRecordSet(FormerTableNowAQuery, dbOpenTable)
akan gagal (karena kueri sekarang, bukan tabel lagi)Peringatan! Cukup cepat diuji terhadap Northwind.accdb di Office 2013 x86 CTR Tidak Ada Garansi!
Untuk pengujian:
sumber
Inventory to reorder Subform for Home
ke bentukInventory
tabelHome
, tanpa masalah. Bahkan tidak disarankan untuk mengikat formulir ke kueri alih-alih tabel (tidak mengikat seperti tabelSelect * From table
?).Table.TableName
notasi. Jika Anda melakukannyaSELECT * FROM TableName
, tentu saja Anda baik-baik saja. Tetapi jika Anda menggunakanTable.TableName
, subformulir Anda akan menjadi tidak terikat jika Anda mengganti nama tabel.TableDefs!MyTableName.OpenRecordset(dbOpenTable)
, (dukungan pencarian indeks), yang saya juga cenderung menggunakan dan juga akan menyebabkan kesalahan dengan pendekatan AndaSaya mengganti
currentDb.Execute
danDocmd.RunSQL
dengan fungsi pembantu. Itu bisa pra-proses dan mengubah Pernyataan SQL jika ada pernyataan pembaruan hanya berisi satu tabel. Saya sudah memilikidual
tabel (baris tunggal, kolom tunggal) jadi saya pergi dengan opsi fakeTable.Catatan : Ini tidak akan mengubah objek kueri Anda. Ini hanya akan membantu eksekusi SQL melalui VBA.
If you would like to change your query objects, use FnQueryReplaceSingleTableUpdateStatements and update your sql in each of your querydefs. Shouldn't be a problem either.
Ini hanya sebuah konsep
(If it's a single table update modify the sql before execution)
. Sesuaikan sesuai kebutuhan Anda. Metode ini tidak membuat kueri pengganti untuk setiap tabel (yang mungkin merupakan cara termudah tetapi memiliki kekurangannya sendiri. Yaitu masalah kinerja)+ Poin: Anda dapat terus menggunakan bantuan ini bahkan setelah MS memperbaiki bug itu tidak akan mengubah apa pun. Dalam hal, masa depan membawa masalah lain, Anda siap untuk
pre-process
SQL Anda di satu tempat. Saya tidak menggunakan metode pembaruan pemutakhiran karena itu membutuhkan akses Admin + akan memakan waktu terlalu lama untuk membuat semua orang di versi yang benar + bahkan jika Anda menghapus, beberapa kebijakan kelompok pengguna akhir menginstal pembaruan terbaru lagi. Anda kembali ke masalah yang sama.Jika Anda memiliki akses ke kode sumber,
use this method
dan Anda 100% yakin bahwa tidak ada pengguna akhir yang mengalami masalah.Sekarang CTRL+F
Cari dan ganti
docmd.RunSQL
denganhelper.Execute
Cari dan ganti
[currentdb|dbengine|or your dbobject].execute
denganhelper.execute
Selamat bersenang-senang!
sumber
Ok, saya juga akan berpadu di sini, karena meskipun bug ini sudah diperbaiki, perbaikan itu belum terisi penuh melalui berbagai perusahaan di mana pengguna akhir mungkin tidak dapat memperbarui (seperti majikan saya ...)
Ini solusi untuk saya
DoCmd.RunSQL "UPDATE users SET uname= 'bob' WHERE usercode=1"
. Cukup komentari permintaan yang menyinggung dan masukkan kode di bawah ini.Saya tidak bisa mengatakan itu cantik, tapi itu menyelesaikan pekerjaan.
sumber