As one user already pointed out, stored procedures, if available, are definitely the preferred way of making multi-table entries and edits. It's basically a transaction and transactions usually allow you to roll back when an error is encounter.
Access 2010 has stored procedure capabilities built into the database engine but prior versions of Access do not. Other popular database servers such as SQL Server and MySQL also have stored procedure capabilities. To run/call a stored procedure in one of these databases you must either use a Pass Through Query or else use ADO.
Access does have an option on the form level to change your Recordset Type to Dynaset Inconsistent Updates. This allows the form to ignore the relationships in the query that underlies your recordset but any relationships defined in your relationships window will still be honored. You can see a discussion on that here: http://www.utteraccess.com/forum/Dynaset-Inconsistent-Upd-t1664392.html
As pointed out in that discussion, I also design my data entry forms so that they are built on only a single table even if I'm using a query. I then use subforms for data that is in related tables. I think this is pretty much standard design practice in MS Access. Software designed in environments such as .NET can easier violate this because usually the developer is having to write code for all CRUD operations anyway. This gives the developer greater flexibility.
