I do know one way that does work without having to export anything, but it is a little cumbersome to setup. Below is a quick summary of what is involved. This technique does require you having at least datareader access to the SQL Server database that's hosting your SharePoint data.
Now for the details....
First off, I'm using Monarch Pro v9, Access 2003 (2007 will work), and SharePoint 2007 services.
Here are some things to be aware of concerning the "UserData" table (this is where the "[I]cumbersome[/I]" part kicks in).
The list's column names are not included. Data is stored in fields such as nvarchar1, nvarchar2, int1, int2, int3, etc. depending on the column type definition when the list was created. However, the list's column names are defined in the "Lists" table, but they are in XML format. So pretty much useless in this solution.
The column order on the SharePoint list isn't necessarily in the same order as the field names in the database table. For instance: If the SharePoint list is in the order of Column1, Column2, and Column3, the data may be stored in nvarchar3, nvarchar1, nvarchar2 respectively. You'll just have to figure out which column in the list matches up to which field in the table.
If a column in the SharePoint list actually references or links to another list, the linking column will more than likely be one of the "int" fields in the database table, which represents the primary ID key of the other list.
In the criteria section of the tp_ListID /Bfield from the "UserData" table, paste (with brackets) the list ID. You can find the list ID using the following steps:
I did try this on my own SharePoint environment and it worked just beautifully. Hope this helps you out... or at least gives you another idea on how to solve this issue. If you don't use my way, I sure would be interested knowing what solution you did come up with.