Query Reference to Remote Database Fails
- Karl Donaubauer
- Dec 19, 2025
- 3 min read
Updated: 2 days ago
Description
You get an error message with a query or SQL text that refers to a remote Access database, e.g. using an IN clause: SELECT * FROM Table1 IN 'd:\Foo\Some.accdb' or direct notation: SELECT * FROM [d:\Foo\Some.accdb].[Table1]
The most common error message is: "Operation is not supported for this type of object." If you try to run the query/SQL from VBA, this is runtime error 3251. The problem can happen within Access or in a different program like Excel that tries to get data from an Access database. Some forum discussions:
Microsoft Q&A
Stackoverflow
AWF
Cause
Microsoft has increased the security measures with regard to the execution of queries in remote databases. An optional registry key for this was already introduced in 2021 with KB5002984. The Office security updates from December 9, 2025, changed the default to block the execution even if the registry key doesn't exist.
Status
From Microsoft's point of view, this is not a bug but a security feature. Therefore, the only solutions available are the workarounds listed below. In early March 2026, Microsoft published a troubleshoot article on this issue.
A solution for a particular situation is available as of version 2601 build 19628.2015, released on Jan 27, 2026. However, it only solves the case where there is already a connection to an Access database and the same database is used again in an IN clause. This type of use, which in practice may e.g. occur in Excel, no longer throws error 3251 with the fix.
Workaround 1
If the problem occurs in a different program than Access, then check whether the registry key described in KB5002984 exists on your system and has the value 0 (=block). If so, you can set it to 1 to allow remote execution of queries from outside of Access. If the key does not exist, you can create it and set it to 1, as described in the KB article.
Update 2026-03-07 |
After it was discovered that the registry key described in the KB article is reset by Office updates, discussions with the Microsoft Access team have led to two results: 1. This information and recommendation: Regarding the registry key being reset on updates: the key was designed as a temporary measure to give people time to adjust their applications, not as a long-term configuration option. We'd encourage anyone who is currently relying on it to look at restructuring their approach so they don't need it. For example, placing their databases in a trusted location, or rearchitecting queries that reference external tables. We understand that isn't always straightforward, but it's the more sustainable path. 2. A tip regarding the registry solution for people who don't want the value removed: The path suggested for MSI installs: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\16.0\Access Connectivity Engine\Engines
Will also work for C2R installs (if the ClickToRun path value is not set), and will NOT be removed by Office updates. Microsoft is also working on a new HKCU path to facilitate the setting. We will inform you here when we know more details. |
Workaround 2
If the problem occurs from within Access, it helps to declare the database with the external reference as Trusted (or set "Allow all macros").
Workaround 3
Especially if you do not have the permissions for the other workarounds:
Another method to avoid the reference to remote databases in Access queries/SQL is to use linked tables. So instead of using a SQL text like mentioned in the Description section above, you can create a link to Table1 in d:\Foo\Some.accdb, and then use the local linked table in your query or statement: SELECT * FROM Table1
If you need to reference different tables dynamically you can create or modify the link with VBA code using methods like TransferDatabase and RefreshLink.
Workaround 4
A temporary remedy is to roll back to an older build of Office/Access in which the problem does not yet occur, i.e. to 19426.20170 of Dec 3 or earlier.
If you encounter a variation of this problem, feel free to describe your specific issue in a comment on this article so that we can inform Microsoft about it.
We have thousands of queries that are now triggering this error due to the latest Office update. This update has been catastrophic for us; it effectively destroys a decade of painstaking work and development spent building our Excel VBA and Access database infrastructure.
Our system is far too massive and the logic too complex to undergo 'redesign' or 'rearchitecture' as Microsoft suggests. We firmly believe that users should have the right to choose whether to enable or disable Remote Queries based on their own specific operational needs and risk assessments.
In the most recent update, Microsoft again removed the registry key workaround, which has once again severely impacted our operations. We are submitting this feedback to demand that Microsoft face…
Some of my users are now reporting that this issue is no longer a proble in a recent update. Can anyone else confirm?
Important to note that the Reg Key in question was implemented in 2021, but the Dec 9th update changed the default value from 1 to 0. So, if your system did not have the reg key prior to Dec 9th update, it defaulted to 1 and all was good in the world of IN '' [some connection string], but after the update, it defaults to 0 and then boom -- all is not good in the world of IN '' [some connection string]. For me, the issue popped up using an SSIS package in which I used an ACE engine instance instantiated using an Excel file to pull data from SQL Server to write data into a new Excel sheet. SELECT
Microsoft changed something in recent Access builds and suddenly queries that reference another database with the IN 'other.accdb' syntax just stop working even though they’ve been fine for years. It’s being brushed off as a security change, not a bug, so waiting for a fix is probably wishful thinking. At this point the safest move is to stop using remote IN queries altogether and switch to linked tables or another approach, because this is clearly legacy behavior getting quietly shut down.
Not having an issue so far. Looks like the previous developer was smart enough to add code to add the hard coded locations for the DBs called by IN as Trusted Locations.