ГлавнаяMS ACCESS Редактирование данных ODBC или первичный ключ в связанной таблице ODBC
Редактирование данных ODBC или первичный ключ в связанной таблице ODBC
Автор osmor
05.02.2002 г.
Цитировать Гетца становится доброй традицией :-)
Редактирование данных ODBC или
Первичный ключ в связанной таблице ODBC
АлексейВ
01.02.2002
Подскажите, как указать первичный ключ связанной таблицы ODBC при
подключении таблицы в модуле. При Подключении через окно БД выдается
запрос на указание первичного ключа. Пытался создать индекс по полям
ключа - выдается сообщение "Нельзя изменять связанную таблицу".
SSY
01.02.02
Я так и не смог...
Попробуй другой ODBC драйвер, если есть :-)
am
25.07.2001
Серег, ты что, мы же это делали! :
txt = "CREATE UNIQUE INDEX PrimaryKey ON [" & rsMap![LocName]
& &] (& & rsMap![ViewPrimaryKey] & ")
WITH PRIMARY;"
dbCurrent.Execute txt, dbFailOnError
С уважением, Андрей Митин
ICQ:38607432
http://am.rusimport.ru
SSY
25.07.2001
Это, наверное, без меня делали :)
Однако, купил сегодня (как раз часов в 19:00) Гетца т.2 и на стр.132
прочёл про этот способ. Зря, выходит купил? (шутка, конечно).
ЗЫ: ДиД, я помню, что ты меня туда отсылал. Теперь
буду сам цитировать :))
Пол Литвин (Paul Litwin),
Кен Гетц (Ken Getz),
Майк Гилберт (Mike Gilbert)
ACCESS 2000 Руководство разработчика т.2 (стр. 131-133) Редактирование данных ODBC
Подключившись к серверной таблице, вы можете неожиданно для себя обнаружить,
что она доступна из Access только для чтения. Дело в том, что Jet допускает
редактирование лишь тех внешних таблиц (не-Access формата), у которых имеются
уникальные индексы. Когда вы подключаетесь к таблице из источника данных
ODBC, Access использует ее кластерный уникальный индекс в качестве первичного
ключа.
Если такого индекса нет, Access использует в качестве первичного ключа первый
(по алфавиту) уникальный индекс. В результате:
- при отсутствии уникального индекса таблица доступна только для чтения;
- желая использовать в качестве первичного ключа конкретный индекс, вы должны
назвать его так, чтобы в алфавитном списке он предшествовал остальным (например,
AAA_PrimaryКеу), или сделать его кластерным уникальным индексом.
Если окажется, что у нужной вам таблицы нет индексов, проблему можно будет решить
одним из двух способов. Во-первых, можно создать индекс средствами сервера, а
затем удалить из приложения Access связь с таблицей и установить ее повторно.
(Это заставит Access запросить у сервера новую структуру таблицы.) Если за серверную
базу данных отвечает кто-то другой, этот метол будет наилучшим, поскольку изменение
структуры таблицы на сервере сделает ее доступной для чтения и записи для всех
пользователей.
Во-вторых, можно создать псевдоиндекс. Access 2000 сама предлагает сам это сделать,
когда вы организуете связь с серверной таблицей, не имеющей уникального индекса.
В этом случае перед вами появится диалоговое окно, в котором можно выбрать любой
набор полей с уникальными значениями.
В качестве альтернативы в Access можно создать псевдоиндекс с помощью DDL-запроса.
Вот его общая форма:
CREATE UNIQUE INDEX индекс ОN таблица (поле [ASC|DESC] [, поле [ASC|DESC], ...])
Но в любом случае Access будет поддерживать локальный индекс для связанной таблицы
и вы сможете ее редактировать.
Примечание:
Индексы, созданные посредством DDL-запроса, можно увидеть в диалоговом окне
свойств индекса в Access. Однако ни создавать, ни удалять, ни модифици-ровать
индексы связанных таблиц ODBC в этом окне нельзя. Это можно делать только
с помощью DDL-запросов.
Внимание:
Созданный таким образом локальный индекс существует только для вашего удобства,
а значения составляющих его полей могут оказаться неуникальными, поскольку сервер
за их уникальность не отвечает. Так что будьте аккуратны с такими индексами! Создав
локальный индекс на основе неуникальных полей, при обновлении серверных таблиц
вы можете столкнуться с неприятностями.
Любую таблицу с уникальным индексом можно обновить, но выполняется такая операция
не всегда одинаково быстро. К счастью, кое-что здесь можно оптимизиро-вать.
В частности, если ваш сервер поддерживает тип данных Timestamp, таблицы с полем,
где такие данные содержатся (это поле даты/времени, которое сервер обнов-ляет
каждый раз, когда изменяется любое другое поле записи), обновляются гораздо
быстрее других. Когда Jet обновляет строку через ODBC, последняя должна гаран-тировать,
что никакой другой пользователь не изменит запись, пока ее редактируете вы.
Обычно для этого Jet в начале и в конце процесса редактирования извлекает из
таблицы все поля, кроме MEMO и OLE, и проверяет, не изменились ли их значения.
Если же в таблице имеется поле Timestamp, Jet достаточно сверить значения только
этого поля и сразу станет ясно, модифицировалась ли кем-то запись с тех пор,
как вы начали ее редактировать.