how to export odbc information from access 2010

Wouldn't it be Server - 1:m - SQL Database - 1:m - ODBC - m:m - Access database - 1:m - Table?

I agree with Ken that at this point your best bet may involve a simple one-table form for Access databases, with a subform for Tables. You could just manually enter the few Servers directly into the table; I have no way to know if you're dealing with four or forty SQL databases but you could enter them as well, either in the table or in a simple one-table form.

That would let you just put combo boxes on the Access Database form for the ODBC and Database fields. Nested subforms may well be overkill.

If you could post your current tables, with primary and foreign keys, it would help. I'm cooking supper (lentil dhal, cardamom basmati rice and spicy mustard greens <g>) but I'll be checking back over the evening.

John are you still with me...i did create three junctions for all of them except the server to ODBC tables as that i though would be the one to many relation ship.

You said earlier:

"when you put your mouse over a table name it shows what server it uses, what the odbc name is,  what sql database it uses, what access database it uses and what the table name is"

That suggests to me that you want to enter then data in a 'bottom-up' manner, i.e. from

the above information you enter the table name, then the Access database name, and so on up the hierarchy to the server.  If you are intending to proceed that way, then a single Servers form with nested subforms would not be very suitable, as that presupposes a 'top-down' approach, entering the server name first then proceeding down through the hierarchy.

If you do intend to follow the 'bottom-up'  approach I think that a set of independent forms in which you select the next level up from a combo box would fit the bill better, i.e. you'd start with a Tables form, entering the table name, and selecting the Access database name from a combo box.  If the database name is already in the combo box's list you can then proceed to enter the next table record in the form.  If the database name is not yet in the list then you'd type it in and this would cause code in the combo box's NotInList event procedure to execute and open a form to enter the new database name.  This process would continue through a sequence of forms until you enter the server name.

To start with you'd be progressing through all the forms right up the hierarchy to the servers form, but as you gradually enter rows into the tables up in the hierarchy in this way the values would be added to the combo boxes' lists and you'd be able to select from the list, e.g. if, as would be expected, you enter all the tables from one database in sequence, once you'd proceeded through the various forms to add the higher levels of the hierarchy for that database, you'd simply select the database name in the combo box as you enter its various tables, with no more to do until you move on to the set of tables for another database.

You can see how this would work with the NotInList demo file I mentioned earlier, available at:

https://skydrive.live.com/?cid=44CC60D7FEA42912&id=44CC60D7FEA42912!169

Try adding a new contact in the first form in the demo and then add a new city and region for that contact.  That's analogous to your hierarchy  Then add another contact and a new city, but select the region you added for the first contact.  Finally add another contact and select the same city as one of the other two.  You'll see that as you build up the city and region data there is less to do for each new contact.  In the same way as you build up the database and other data in the levels above the Tables table there'll be less to enter.

This presupposes a straight linear hierarchy from tables up to servers however.  At this point I should apologise for leading you astray earlier by unthinkingly following the order of levels as you'd set them out and getting the SQLDatabases and ODBC tables the wrong way round, as John pointed out.  I was under the impression from your description that your hierarchy was a straightforward linear one of one-to-many relationship types, but John has correctly pointed out that this might not necessarily be the case, and from what you've said you do appear to have created a table to model a many-to-many relationship type.  However, you have not said which entity types this many-to-many relationship type is between, or indeed whether there is more than one.  And are you sure you really do have such a many-to-many relationship type?  As John said earlier, if you don't then there is no need to model one with a so-called 'junction table'.  If you do then the existence of the additional table(s) would need to be reflected in the forms used for entering the data.

I'm signing off for the night now.  I don't know what time it is where you are, but even the owls have gone to bed here!