【问题标题】:MS-Access Oracle Linked-Table Primary Key errorsMS-Access Oracle 链接表主键错误
【发布时间】:2015-07-18 03:38:02
【问题描述】:

在将 Oracle 数据库与 MS Access 链接时,我一直试图找出哪个键是主键 (PK)。

在链接表上右键单击并选择 Design View 会打开一个页面,解释每个字段中保存的数据类型,例如短文本,它还在特定字段旁边包含一个 key 符号并显示 @987654324 @。

我对此持怀疑态度,因为我做的第一个表显然有一个由 5 列组成的复合主键,其中两列实际上可能是空的。我在网上进一步扎根,找到了this Oracle page。看起来,通过查看ALL_CONS_COLUMNS 表,您可以看到实际的 PK - 并且您瞧,我似乎可以,并且在前面的示例中给出的表中只有一个 PK。

然而,在这个 ALL_CONS_COLUMNS 表中似乎有一个奇怪的事件,对于有问题的表,它将 PK 列为对两列的约束(注意:不是复合键,它表示对 column_x 的约束是 column_x是一个 PK,并且它还相当随机地声明​​ column_y 的一个约束是 column_x 是一个 PK)。

所以,任何关于为什么的帮助:

  1. MS-Access 导入 PK 完全不正确。

  2. 为什么ALL_CONS_COLUMNS 表会在列上随机添加不正确的约束?

我现在使用的是ALL_CONSTRAINTS表,它是正确的,即它只包含一个约束,即Table_X的PK是Column_X。

提前致谢!

【问题讨论】:

    标签: database oracle ms-access


    【解决方案1】:

    ALL_CONSTRAINTS 不显示哪些列是主键约束的一部分。 CONSTRAINT_TYPE 列将告诉您一个特定的约束是 Primary Key 约束,但您需要查看 ALL_CONS_COLUMNS 以找出主键由哪些列组成。另请注意,您不一定能从其名称中判断一个约束是否是主键,因为非主 Unique 约束可以命名为 TABLE_PK,即使它不是主键。

    Access 可能会采用它在链接表上找到的第一个唯一约束并将其作为主键。

    此查询是否将您的约束显示为单列或复合主键?

    select ac.OWNER
         , ac.TABLE_NAME
         , ac.CONSTRAINT_NAME
         , case when max(nvl(position,0)) over (partition by ac.OWNER, ac.TABLE_NAME, ac.CONSTRAINT_NAME) > 1 then 'Composite '
           end ||
           case ac.CONSTRAINT_TYPE
             when 'P' then 'Primary Key'
             when 'U' then 'Unique'
             when 'R' then 'Foreign Key'
             when 'C' then 'Check'
             else ac.CONSTRAINT_TYPE
           end CONSTRAINT_TYPE
         , acc.COLUMN_NAME
         , acc.POSITION
      from all_constraints ac
      join all_cons_columns acc
        on acc.OWNER = ac.OWNER
       and acc.TABLE_NAME = ac.TABLE_NAME
       and acc.CONSTRAINT_NAME = ac.CONSTRAINT_NAME
     where ac.owner = user
     order by ac.table_name
         , ac.CONSTRAINT_NAME
         , acc.POSITION;
    

    【讨论】:

    • 检查ALL_CONS_COLUMNS 显示复合主键;但是,您是否建议它可能不是,它实际上是一个主键,但它也显示一个唯一约束,名为 TABLE_PK
    • 不,我的意思是约束的名称不一定表示它的功能。我可以使用名为TABLE_U1 的单列或多列主键和名为TABLE_PK 的非主唯一约束创建一个表。指示约束函数的是CONSTRAINT_TYPE 列。
    • 我知道了!谢谢。进一步深入数据库,我发现了各种奇怪的命名约束,其中 suggest 列是 PK,而实际上完全不同的列是。奇怪地将数据库放在一起,但多亏了你,我可以从小说中破译事实。
    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 2012-10-15
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2010-09-29
    • 1970-01-01
    相关资源
    最近更新 更多