Recent content by mellamokb

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...

Just want to say - thank you both for engaging with this question, as I didn't really know where to turn for advice! Yes, E:\ is a Dev Drive and marked as a Trusted Location with the registry key, makes no difference with the above. Also, a simple query against the database works fine like...

So, I guess I didn't realize an important detail that mattered. It is specifically the use of DAO via COM interop with a C# script. Apparently this is getting a different result than using DAO via VBA code, which I am surprised to see a difference because I assumed them to be fundamentally...

32bit.. I don't know exactly what version I was on before but I'm on the Monthly Channel. On another machine I have 2404 Build 17531.20190 and don't get the error.

Wasn't sure the best place to ask about this. But we noticed queries of this form: Select * From Table1 Inner Join [C:\Data\File.Accdb].Table2 ... Are now giving an error 'Operation is not supported for this type of object' when running from DAO Database.Open call. It works fine in the Access...

Yeah, that is a good suggestion. When the user is done working with employee management it could probably do the reorder once afterward. The general problem is I know there are numerous places in our production application where recordset loops are used to batch process and I was hoping to...

Hmm. I added the folder with my Test database as Trusted Locations and the behavior seems similar. I suspect because I'm comparing performance between two different function in the same database, not two different databases.

Yeah, that's the conclusion I'm coming to as well. What's annoying is that the listbox doesn't have this behavior without the Data Macro. You can happily do a recordset loop and update every record in the listbox with no performance hit. The problem seems to only manifest in combination of a...