Just re-visited this problem and this quote from the above tutorial highlights the work-around...
When working with relational databases, it is common for
queries to pull their data from multiple, related tables. Correlated subqueries
and JOINs provide two different techniques for
accessing data from related tables in a query. In previous tutorials we most
commonly made use of correlated subqueries because the TableAdapter cannot
auto-generate INSERT, UPDATE,
and DELETE statements for queries involving JOINs.
While these values can be provided manually, when
using ad-hoc SQL statements any customizations will be overwritten when the
TableAdapter Configuration wizard is completed.
Fortunately, TableAdapters created using stored
procedures do not suffer from the same brittleness as those created using
ad-hoc SQL statements. Therefore, it is feasible to create a TableAdapter whose
main query uses a JOIN when using stored
procedures. In this tutorial we saw how to create such a TableAdapter. We
started by using a JOIN-less SELECT query for the
TableAdapter’s main query so that the corresponding insert,
update, and delete stored procedures would be auto-created. With the
TableAdapter’s initial configuration complete, we augmented the
SelectCommand stored procedure to use a JOIN
and re-ran the TableAdapter Configuration wizard to
update the EmployeesDataTable’s columns.
Re-running the TableAdapter Configuration wizard
automatically updated the EmployeesDataTable columns to reflect
the data fields returned by the Employees_Select stored procedure.
Alternatively, we could have added these columns manually to
the DataTable. We will explore manually adding columns to the DataTable in the
next tutorial.