Recent content by mellamokb

@isladogs - sincerely appreciate the additional updates, apologies as I was on vacation last week and so now am just getting back to this. 1. I tested the registry file run from VBA - in non-admin user it prompts for UAC admin permission so I think that is no different than running it on...

@isladogs - Thank you for forwarding the message. I deeply appreciate your time and effort in helping understand and express this issue. We are in this situation of our own making because of our reliance on Access BE for such a long time, but it has been such a remarkably good solution for our...

I am fine with the change and understand the security implications. What I'm not fine with, is not considering some use cases and just throwing customers under the bus (who they actually serve, not the other way around). We have been a diligent customer of Microsoft products and sold an...

Sorry I did not see your reply @isladogs - Yes, the registry key keeps getting forcibly removed. I haven't been able to correlate it obviously with a Windows/Office Update because I haven't kept close enough track. I am working on a .NET code project that heavily relies on IN clause feature...

So.. I'm not 100% sure what's going on, but I feel like I've had to re-apply this same fix multiple times to the same machine. I can't really prove it but it seems as though the registry key is getting unset by some process and requires me to keep re-setting it again. Does that make any sense...

Thanks for the update. We also found in the meantime that another of our products was affected in a similar way that wasn't even on my radar but does a similar IN clause query from a .NET application. In our use case the only viable workaround will likely be to enable AllowQueryRemoteTables...

I saw there was a new release to the Current Channel on Thursday - 19530.20138 - I tested it with the script above and still get the same error. Do we have any updates on whether this is still being addressed with another release?

Yes that is just a simple test to demonstrate the issue, so I output the rs.RecordCount value. In the production code we read out all of the recordset fields and rows into objects for processing from many tables, and then insert thousands of rows back into tables at the end in a transaction...

Awesome glad to hear! Yes this is exactly the issue, appreciate your help in reviewing this. And thanks for your patience sorry for all the posts to get to the explanation. I really hope they plan to fix this but I could understand we are probably well outside of normal usage.

You probably need the 64-bit version of LINQPad since you have the 64-bit Access/drivers installed (look for the message Running massive queries in LINQPad 5? on the download page). I'm not sure if it will work with the script I provided with no other changes, as I've never used 64-bit Access...

Yes sorry I do mean v2509 and v2510. I have attached the files I used in the repro test above. - test1.accdb - has tblItem1, and a static query reference to tblItem2. Expected to be located as E:\test1.accdb - test2.accdb - has tblItem2, and a static query reference to tblItem1. Expected to...

So I have confirmed that downgrading to v1509 (19231.20246) from November 11 fixes the error. I have also confirmed on a 3rd machine that upgrading to the v1510 build gives the same error trying to make cross-database DAO calls. On the 2nd machine where the Dev saw the problem a week prior and...

Sorry, I may have misspoke - we are currently on Monthly Channel on our entire team, not Current Channel. Based on the release notes this appears to be the latest version and was released Dec 09, which is roughly when the problem started occurring for me.

So I have confirmation from another Dev on the same team that he was getting the same error for about a week, and then the error went away. As far as he can tell, no changes were made to his environment or configuration during that time. The error simply appeared, and then seemed to disappear...

It does look like a linked table works with the code above. However that is untenable for our current design since we need to relink hundreds of tables every time the user switches clients, and the IN clause based method is by far the fastest. Our largest ISV customers have 10K or more client...