All codes that run on SQL Server stay on the server.  But are your data on the server too, are they local data that have to be uploaded to the server first?  If you upload 30k rows to the server, that is never going to be fast.  All web apps must be designed to make *minimal* number of reads and writes and minimal data per read and write -- because Internet speed is still nowhere as fast as local speed.  Reading/writing 30k rows may be okay as a one-off.  But if it's a regular occurrence, you need to change your design.

Yeah, you definitely do not want to be pushing 32,000 records one at a time. Access will happily sit there and grind away, but it will take hours, like you said. The problem is not really the amount of data, it is the ODBC and database overhead of opening and closing all those individual transactions. That overhead adds up fast and kills performance long before the raw data size would.

What I usually do is build a single pass-through SQL statement and let SQL Server handle it. That way the data moves in bulk, not piecemeal. If you are working with tens of thousands of rows, break them into chunks of a few thousand each so you are not building one monster string that chokes memory, but still avoid the row-by-row overhead.

This is one of the big themes I will be covering in my upcoming Access-with-SQL-Server series. Access is great for front-end forms and reporting, but when it comes to large updates, let SQL Server do the heavy lifting. That is how you get speed.

I would put all the tables that receive heavy periodic updates in a separate database on SQL Server.  Whenever I have a new version of those tables, I just upload the whole database to SQL Server on Winhost.  That is much less resource-intensive than running queries to do the updates.