2009-08-02 2 views
1

У меня есть таблица под названием table1, которая имеет составной первичный ключ с использованием «ScreenId» и «ActivityItemId». Я добавил новое поле «ProductId», которое имеет ограничение NOT NULL. Я хочу добавить ProductId в составной первичный ключ.SQL (access) - добавить новое поле в составной первичный ключ

Я думал, что это будет работать

db.execute "ALTER TABLE table1 PRIMARY KEY (ScreenId, ActivityItemId, ProductID)"

, но я получаю сообщение об ошибке, я думаю, что этот синтаксис работает только при создании Таблица.

Может ли кто-нибудь помочь мне с SQL? (Я не могу использовать визуальный базовое решение здесь кстати, я на самом деле с помощью интерфейса рубиновый, чтобы запустить SQL, поэтому он должен быть только в SQL)

благодаря Макс

ответ

6

Попробуйте Оставьте свой текущий первичный ключ, а затем создать новый:

ALTER TABLE table1 DROP CONSTRAINT pk_name

ALTER TABLE table1 ADD CONSTRAINT pk_name PRIMARY KEY (ScreenId, ActivityItemId, ProductID)

+0

Thanks Hawx - но я получаю эту ошибку Код ошибки OLE: 80004005 в Microsoft JET Database Engine Ограничение CHECK 'Первичный ключ' не существует. Я запускал это - может быть, это не правильный синтаксис? "ALTER TABLE table1 DROP CONSTRAINT [PrimaryKey]" –

+1

Вместо [Первичный ключ] используйте имя основного ключа. –

+0

ах я вижу, квадратные скобки, как в «вставить переменную здесь» \ п Еще не повезло я не боюсь - я буду выполнение этого:. ALTER TABLE DROP CONSTRAINT активность ScreenId и я получаю эту ошибку назад Ограничение CHECK 'ScreenId' не существует. ScreenId определенно является одним из основных полей ключа в этой таблице. Это база данных доступа - существует ли другой синтаксис для доступа, возможно? спасибо большое - max –

3

Думай о суррогатный ключ вместо сложного ключа. Вы не хотите менять свою схему каждый раз, когда изменяется ваша бизнес-логика.

Возможно, стоит сохранить эти отношения как уникальные ограничения и добавить суррогатный ключ.

+1

+1: «Композитный первичный ключ», который не является основным. Он изменился, поэтому он не является «единственным и единственным идентификатором строки. Сделайте составной ключ обычным индексом и добавьте уникальный суррогатный ключ. –

+0

Спасибо Duffymo.На самом деле это не моя бизнес-логика, мы не будем использовать доступ для нашего бизнеса :) Это действительно одноразовая работа.
Сказав, что я не прочь использовать суррогатный ключ для решения проблемы, я еще не слышал этого термина. Я посмотрю. –

+0

Очень хорошо, Макс. Если вы используете Access, добавьте столбец с именем id, который имеет тип AutoNumber, и все в порядке. Используйте уникальное ограничение для других столбцов. – duffymo

-1

Вы пытались изменить первичный ключ с помощью представления дизайна вместо использования SQL?

+0

-1 они сказали: «Я действительно использую интерфейс ruby ​​для запуска sql, поэтому он должен быть только в SQL». – onedaywhen

+0

ООП! Виноват. Мне все же было бы интересно узнать, с какими движениями интерфейс интерфейса проектирования позволяет вам выполнить эту задачу. Макс получил решение, которое искал, как только узнал, как назвать ограничение, которое он пытался сбросить. Все хорошо, что хорошо кончается. –

+0

Одна вещь об использовании интерфейса, о котором я не уверен, заключается в том, как указать другой из столбцов в PK i.e. ScreenId, затем ActivityItemId, затем ProductId в этом порядке. Это очень важно, если учесть, что механизм базы данных Access использует ПК для физического кластеризации данных на диске. Что делать, если пользовательский интерфейс всегда добавляет новый столбец после всех остальных? Как узнать, было ли это так или нет? Из-за неизвестных мне безопаснее использовать SQL DDL. – onedaywhen