If you have a query that is not updateable, check out Allen Browne's Tips on what might cause this: http://allenbrowne.com/ser-61.html
MS Access has a shortcoming. If you wish to edit data in list-like views, it generally works best for it to be displayed in basically the same structure that it's stored in your tables. Edit: In reference to the comment left by Yawar about this not being an Access shortcoming, I'd like to point out that when developing in .NET it isn't uncommon to have a database structure that is quite unlike the data model classes used inside your application. In this case the GUI is built on the data model so the database may look somewhat (or event quite) different from your data models/GUI.
Back to MS Access, when you use a table join to create the recordsource/recordset for a datasheet form or continuous form, it's my understanding that only one of the tables is going to be updateable. In other words, only one side of the join is updateable. And in many cases, the recordset is not updateable at all, due to the DAO engine being confused. Update: I have deduced from the link below that what I wrote above seems to be more true of SQL Server than using JET/ACE backend.
The most common solution is as HansUp has suggested, use a form/subform approach. You can actually have a datasheet subform as a child of another datasheet subform, which would work quite well in your case here. There will just be an expandable plus sign at the far left of each record so you can add/edit/delete the record(s) in tblTwo.
Another option is to use an ActiveX grid control such as the iGrid from 10tec which means you'll write quite a bit of code for all kinds of things, like loading the recordset, writing changes/additions/deletions back to the database, handling formatting of cells, etc.
Yet another option is to use a fabricated ADO recordset. This is a terribly clumsy approach and I can't say that I've really seen it in use, mostly just experimented with it and read about it in theory. The problem is that you have to create a fabricated recordset that is nearly identical to the one that you generated, and then you have to loop through and copy all of the records from the generated recordset into your fabricated recordset. It's a tremendous amount of overhead, especially for that many records. And then, you must write code once again to write all additions/changes/deletions back to the database. Handling the creation of new primary keys can be tricky. This particular approach is not easy or simple and is not something I recommend a VBA beginner tackling.
If you're using SQL Server you should check out the following article at Microsoft's website. It covers a variety of material including updating multiple tables from a single recordsource/view. http://technet.microsoft.com/en-us/library/bb188204%28v=sql.90%29.aspx