how to export odbc information from access 2010

Anonymous
2012-02-17T17:33:20+00:00

Is there a way to export linked information in access 2010.  For instance the odbc, server& database names associated with each table?  I found the documenter but that is only for one table and is a mess in excel.

Microsoft 365 and Office | Access | For home | Windows

Locked Question. This question was migrated from the Microsoft Support Community. You can vote on whether it's helpful, but you can't add comments or replies or follow the question.

0 comments No comments
Answer accepted by question author
Anonymous
2012-02-20T05:56:32+00:00

Please post the SQL view of the recordsource of the form and the rowsources of the four combo boxes.

The relationship DOESN'T ACTUALLY MATTER at this point. You do need the relationships, but they won't affect how the form works!

My idea was that you would have tblTablenames with fields (I don't remember and can't scroll back to see them) for AccessDatabaseID, ODBCID, SQLDatabaseID and ServerID, as the Recordsource for your form; the form would not have ANY other tables involved at all. It would have a textbox for the table name and four combo boxes, based on the appropriate tables (AccessDatabases, ODBC, SQLDatabases, Servers) and bound to those four ID fields. You would type in the tablename, and then select the appropriate choices from the four combo boxes. Then you'ld move to the next tablename, and so on.

I haven't any trace of a clue what you mean by "it doesn't work... it shows four records at the bottom".

Again: If you're basing the Form on this multitable query, DON'T. That's not how relationships work, that's not how forms work!!!!

Was this answer helpful?

0 comments No comments
Answer accepted by question author
Anonymous
2012-02-20T04:33:26+00:00

Add fields AccessdbID, ODBCID, SQLdbID and ServerID to tblTableName.

You can then use a Form with combo boxes bound to those fields, based on your database, odbc and SQLdb and Server tables.

It's not quite normalized but a) I think it will meet your current needs and it will be quick and b) it can be used to populate normalized tables if you need to move there.

Was this answer helpful?

0 comments No comments

70 additional answers

Sort by: Oldest
  1. Anonymous
    2012-02-20T00:47:52+00:00

    Ok i recreated it ....server name in header ..odbc in detail but when i click on next record odbc doesn't change.  I did get it to show up though.  I really think we are almost there.  I'm not sure what i'm doing wrong with the subform.

    Was this answer helpful?

    0 comments No comments
  2. Anonymous
    2012-02-20T01:30:15+00:00

    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!

    Was this answer helpful?

    0 comments No comments
  3. Anonymous
    2012-02-20T01:42:37+00:00

    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.

    Was this answer helpful?

    0 comments No comments