Упредить

← →
IGray (2003-11-20 23:31) [0]

Допустим, в таблице Table1 есть некое уникальное
поле которое после редактирования пользователем
должно остаться уникальным. Как ДО выполнения Post
проверить нет ли уже такого значения в Table1?
(чтоб при необходимости попросить пользователя ввести
другое значение). Брать Post в try..except не хочется,
так как таких уникальных полей в записи несколько,
а способа понять какое именно из полей вызвало
"Key Violation" (для подсказки пользователю) я не знаю...

← →
Johnmen © (2003-11-20 23:41) [1]

Может дело в недоработанной структуре таблице ?
С трудом можно представить такую таблицу, в которой несколько уникальных полей...:)

← →
Zacho © (2003-11-20 23:41) [2]

Например, OnPostError

← →
Zacho © (2003-11-20 23:42) [3]

> Johnmen © (20.11.03 23:41) [1]

Почему же ? Первичный ключ всего лишь один из потенциальных ключей :)

← →
Johnmen © (2003-11-20 23:46) [4]

>Zacho © (20.11.03 23:42)

Не понял... :) Причем здесь ПК ?

← →
Zacho © (2003-11-21 00:02) [5]

> Johnmen © (20.11.03 23:46) [4]

Просто я придерживаюсь мнения, что любое unique constraint==потенциальный ключ. Может, я и не прав.
Кстати, пример таблицы с несколькими уникальными полями: таблица Менделеева ;)

← →
mfender © (2003-11-21 00:32) [6]

Я, обычно пишу что-то вроде того:
function TfrmMain.UnID(Tab: TQuery; TabName: String; IdFld: TField): string; var cod: Integer; begin with Temp do begin Close; SQL.Clear; SQL.Add("SELECT * FROM "+TabName); Open; end; Cod:=1; while (ValueCompare(Tab,IdFld,IntToStr(Cod))=True) do begin Inc(Cod); if Length(IntToStr(Cod))>IdFld.Size then MessageDlg("

← →
Zacho © (2003-11-21 00:39) [7]

> mfender © (21.11.03 00:32) [6]

OnPostError не менее действенно и гораздо проще :)

Вот пример:

procedure TfmNorm.ibdsNormPostError(DataSet: TDataSet; E: EDatabaseError; var Action: TDataAction); begin if pos("FK_NORMA",E.Message)>0 then begin ShowMessage("Не выбран контрагент !"); Action:=daAbort; exit; end; if pos("PK_NORMA",E.Message)>0 then begin ShowMessage("Такая норма уже существует !"); Action:=daAbort; exit; end; Action:=daFail; end;

← →
Zacho © (2003-11-21 00:57) [8]

> Zacho © (21.11.03 00:39) [7]

P.S. Пример конечно корявый и топорный, но иллюстрирует то, что информацию о происхождении ошибки (кстати, в этом примере нет, но можно и искомое автором вопроса имя поля) можно взять из текста сообщения об ошибке.

← →
Johnmen © (2003-11-21 09:12) [9]

>Zacho © (21.11.03 00:02) [5]
>Просто я придерживаюсь мнения, что любое unique constraint == потенциальный ключ.

Вот. Рассуждаем дальше. Допускаем, что потенциальный вдруг стал реальным. Вопрос - зачем в одной таблице несколько ключей ?
:))

>...таблицы с несколькими уникальными полями: таблица Менделеева ;)

Ну пара полей, ну три, ещё можно объяснить по жизни. Но большее количество...Лично я не могу...

← →
Nikolay M. © (2003-11-21 09:29) [10]

> Johnmen © (21.11.03 09:12) [9]

+ Еще вопрос - зачем юзеру разрешать редактировать такие поля?
Станет в таблице 1 000 000 записей и юзер будет давить на кнопки, пытаясь ввести неуникальное значение среди существующих? Это уже садизм, имхо...

ПС
"Верх упорства - вводить неправильный пароль до тех пор, пока компьютер не согласится".

← →
Zacho © (2003-11-21 09:34) [11]

> Johnmen © (21.11.03 09:12) [9]
> Вот. Рассуждаем дальше. Допускаем, что потенциальный вдруг
> стал реальным.

Что значит реальным ? Есть потенциальные ключи, из них выбирается первичный ключ. И что здесь реальное, а что не реальное ? :-)

> Вопрос - зачем в одной таблице несколько ключей ?

А зачем Солнце восходит на Востоке ? :-)))

← →
Johnmen © (2003-11-21 09:39) [12]

>Zacho © (21.11.03 09:34)

Я не улавливаю, к чему ты клонишь или на что намекаешь...
:)
И, по-моему, ты слишком "в лоб" понял мой пост.

← →
Zacho © (2003-11-21 09:48) [13]

> Johnmen © (21.11.03 09:39) [12]

Да не на что не намекаю :) Просто странный вопрос "зачем ?" Ну есть несколько ключей, и все тут, по жизни так сложилось :-)

> И, по-моему, ты слишком "в лоб" понял мой пост.

Может быть.

> Nikolay M. © (21.11.03 09:29) [10]
>
> + Еще вопрос - зачем юзеру разрешать редактировать такие
> поля?

Неужели ты это серьезно ? Тогда объясни нашему бухгалтеру, что отныне запрещается редактировать инвентарные и табельные номера и т.д. и т.п. :-)

← →
Danilka © (2003-11-21 09:50) [14]

[1] Johnmen © (20.11.03 23:41)
>С трудом можно представить такую таблицу, в которой несколько уникальных полей...:)

например, реквизиты физлица - уникальными будут и паспортные данные и ИНН и номер полиса ПФР.

← →
Johnmen © (2003-11-21 09:52) [15]

>Danilka © (21.11.03 09:50)

Ну три поля... А больше ? :)

← →
Nikolay M. © (2003-11-21 09:53) [16]

> Zacho © (21.11.03 09:48) [13]

Да, серьезно.
Я за всю жизнь не издевался настолько над юзерами, чтобы заставлять их вводить такую информацию. Генерацию номера счета в банке тоже предложишь руками делать? Да тебя сразу пристрелят.
А зачем нужно редактировать инвентарные номера? Насколько я в курсе проблемы, за каждым стулом закреплен свой ИН - с какой стати разрешать его вводить руками или редактировать?

← →
Johnmen © (2003-11-21 09:55) [17]

>Zacho © (21.11.03 09:48) [13]
>...по жизни так сложилось :-)

Вот я и думаю, может разобраться в жизни, упорядочить её ?
:-))

>Johnmen
Вот я сейчас сижу программку делаю, таблица со списком дисциплин в школе. Поля ПК и Наименование. Так, по моему, вполне нормально, что значения в поле должны быть уникальными

> Nikolay M. © (21.11.03 09:53) [16]

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

Еще пример, который приводил Danilka © - реквизиты физ.лица. Неужели и их нельзя редактировать ? И номер паспорта, например, у тебя генерирует программа ?
Вобщем, уникальные поля - они разные бывают, не только сгенерированные программой, и если оно вводяться вручную - то соответственно и редактировать их можно.

← →
Юрий (2003-11-21 10:27) [20]

По моему все решается тривиально просто (по крайней мере я так делал)
В таблице создается ОДНО поле с уникальным индексом
(обычно автоинкрементное)
Затем при редактирование/добавлении новой записи, перед командой
POST, выполняешь проверку table.locate(....), при помощи которой
проверяешь отсутствие/наличие значения в твоих проверяемых
уникальных полях.
Если locate дает TRUE - сообщение юзеру,мол ты не прав браток.
если FALSE - поехали модифицировать запись.
Конечно все твои "псевдо" уникальные поля должны быть индексированы.
При помощи этого способа можешь держать в своей базе хоть сто
уникальных полей
Вот собственно и все решение проблемы

>Рамиль © (21.11.03 09:55)
>Так, по моему, вполне нормально, что значения в поле должны быть уникальными

И по-моему нормально. А в чем проблема ?

>Юрий (21.11.03 10:27)

Да. Так можно делать. Если однопользовательская система, мало данных и тормоза по-барабану...:)

← →
Юрий (2003-11-21 11:23) [23]

>Johnmen

>Да. Так можно делать. Если однопользовательская система, мало данных и тормоза по-барабану...:)

Так мы ведь про условия задачи ничего больше не знаем, как только "как избавиться от ошибки"

НУ а мало даных это понятие относительное.
Например при 100000 записей этот алгоритм работает нормально , при
большем не проверял

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

> Поскольку поступают они к нам извне, а не генерируются системой,
> а операторам свойственно ошибаться.

Ну, это совсем другое дело. Думаю, понятно, что я имел в виду другую ситуацию.
Теперь осталось узнать, как с этим обстоит дело у автора вопроса. Btw, а где автор?!

Упредить Найти похожие ветки