The problem here is the way you have written this. 50,000 rows export should take less then 1 second. In fact, you find Access is faster then most server based systems. However, you have a dsum() command. (how did you do that on other systems - they DO NOT have that command). Get rid of the dsum command, and this will run fast.
So, the first query, it should run fast. But the 2nd one? No, it will run slow due to the dsum() command. You need to get rid that.
However, if your first query is slow, then some detail is missing here. You also don't mention how long this takes (so, "slow" is a relative word in this context).
However, just a quick glance, the first query should run ok speed wise. But the 2nd one? Nope, that's going to run slow.
Also are the tables linked to some other data source (say a network, or some server database?).
I mean, in general, you should get about 100,000 rows per second here easy. However, with a dsum(), then you are in slow turtle land.
So, you might want to make a note of how long this takes, but more important give a heads up on how many rows you are dealing with.
You could (should) try replacing the dsum() with a sub-query, and that may well fix the speed of the 2nd query.
But it is perplexing that the first query is slow? Perhaps my quick "eyeball" is missing something. So, perhaps I would have to look "more' or "closer", but that first query should not be all that slow.
Since it is slow as you note, then perhaps some additional detail is missing here (is a network involved, linked tables, etc?
But, red flags for 2nd query? Yes, the dsum() has to go!
Regards,
Albert D. Kallal (Access MVP 2003-2017)
Edmonton, Alberta Canada