I'll step in on this one.
what's wrong with having Jet/Ace working across the LAN ?
1. EVERY action on a "true" Access BE file is performed by the copy of Access on the workstation used for the operation, which I will call the FE station NOT to be confused with the FE of the application.
Normally, you don't install Office on a server. In particular if you follow network design guidelines published from various sources including federal government guidelines for server farms, a "division of labor" concept means you MAY NOT (as in NOT PERMITTED) install an app on a general back end file server. So you CANNOT do the C&R or other maintenance on the BE server. (Which is why an SQL Server is not usually on the same system that acts as a file server.)
2. IF you are running Access on an FE workstation but are compacting a BE file, even when operating stand-alone (i.e. the FE app isn't active), you are using Server Message Block protocol over the network to read the contents of the BE piecemeal AND to write back the compressed info the NEW BE file, because C&R works that way.
However, if you do a file copy to the FE station and do the C&R on that local copy, you are using straight disk I/O. You eliminate the network as a middle-man. That's TWO file transfer steps you eliminate - SMB from BE (old file) to FE and then SMB from FE to BE (new file). AND you still have disk I/O to read the old file and write the new file anyway. So only TWO I/O steps instead of four.
3. Working on a local copy means your BE copy is relatively safe on the BE server and you are working on a COPY of your critical data.
So if there is a WHOOPS, no biggie. Make another copy of the BE from its safe place and do it again. That safety through isolation is based on (a) a different machine with a different hard drive, which now requires a double bad event that takes down TWO different disk on two different machines in order to lose data, and (b) not being subject to the vagaries of network "gotcha" events.