While the remote use of Access via slow connections to the back end is clearly best avoided, I wonder if the following scenario might work reasonably well.

The need is to simply enter data remotely. No need to retrieve records remotely at all.

If the remote user's input form used an ADO AppendOnly recordset there would be minimal traffic required to support them. Only the new data values and the usual overheads would be required.

I also saw here recently that ADO intrinsically used transactions and rolled back if there was an error. This should take care of interruptions during updates. The back end would be on SQLServer Express.

What would the user see if the transaction did fail?

Any comments would be most appreciated.

The issues is not with what object library we may use or what methods we may need, but rather how we are handling data at low level.

Because Access is file-based, and will perform file I/O operations, connecting Access across an unreliable connection can only promise corruption, even if the requirement are simple.

It would be safer to append the records into a text file, then send it across and have the backend read the text file into the tables.

Of course, you possibly get away with using ADO transactions but because it's still tinkering with a file and nobody else would want to open a MS Word document or MS Excel spreadsheet in similar context, I tend to think it's a "Just because you could, doesn't mean you should." thing.

HTH.

course, you possibly get away with using ADO transactions but because it's still tinkering with a file

But wouldn't Access be sending the transactions over the slow connection to whatever engine SQLServer uses and then that engine changes files when it is happy that it has a valid and complete transaction?

Much like the manual text file. It either all arrives and gets processed or it arrives broken and we discard it and ask for a new copy.

Ah, the difference is that SQL Server has a daemon and Access doesn't.

Basically, with server-based RDBMS, we don't directly interact with files, we talk to a daemon over the TCP/IP or whatever. Daemon gets messages and based upon it, changes files that's always 1) under the exclusive control of daemon, 2) local to the daemon.

SQL Server would suddenly be unreliable if we for instance place the .mdf file on a remote hard drive and required the daemon to travel over the WAN to access the .mdf file.

In Access' case, we're basically running the engine locally, so it has to grab bits and chunks of file across the wire to process the requests.

Would that article help explain things? (http://www.members.shaw.ca/albertkallal/Wan/Wans.html)