Geek Answers Handbook

Why does Access want you to identify the primary key in related tables?

I support users who use MS Access as an interface to view some Oracle tables in our organization. Their typical use is to write custom queries using Access querybuilder, as well as for LOVE Access, because it allows you to create reports for printing without having to submit a lengthy and expensive request-programming process through our technical support department.

When creating a link to an external table, they are sometimes asked to identify the primary key of the table. Of course, how can they have an idea of ​​what the primary key fields will be?

My question is this: why does Access want to know which primary key fields of the linked table are? Indexing should happen in the db source, right?

We recently had a problem when users switched to Access 2007, which was finally “fixed” in two ways: 1) a new ODBC connection, or 2) the definition of another primary key column for the linked table. My technical support tried to insist that I would have to change my practice by informing my users to select the correct primary key field. I argued that it does not matter. But I can not cast aside the thought that MS Access will not ask, it does not matter for something. Just not sure what it could be.

Note. The "problem" is described in this post: Access to the joined Oracle 10g table - query with erroneous results, but no errors.

+5
source share
3 answers

If your users only need read access, for queries and reports, ask them to cancel in response to the Access question about which field to use as the primary key. They should still create the link, but it will be read-only.

Oracle, Access, . , TableDef... DSN . , DSN.

+4

, , , , ? , , SQL.

+2

Not only uses pk to update. Also when creating a heterogeneous compound, i.e. between the odbc table and the local table or tables from different odbc sources, you need to get all the data for the local connection. If pk can loop requests in an external source using pk. This is really good for small local tables and long odbc tables.

0
source

More articles:


All Articles