| Форумы
ЧАТ |
Орешник |
|
| Форумы -» | Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG |
|
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Упредить
IGray © (2003-11-20 23:31:00)
Допустим, в таблице Table1 есть некое уникальное
поле которое после редактирования пользователем
должно остаться уникальным. Как ДО выполнения Post
проверить нет ли уже такого значения в Table1?
(чтоб при необходимости попросить пользователя ввести
другое значение). Брать Postв try..exceptне хочется,
так как таких уникальных полей в записи несколько,
а способа понять какое именно из полей вызвало
"Key Violation" (для подсказки пользователю) я не знаю...
Nikolay M. (2003-11-21 12:53:00) [1]
> Поскольку поступают они к нам извне, а не генерируются системой,
> а операторам свойственно ошибаться.
Ну, это совсем другое дело. Думаю, понятно, что я имел в виду другую ситуацию.
Теперь осталось узнать, как с этим обстоит дело у автора вопроса. Btw, а где автор?!
Юрий (2003-11-21 11:23:00) [2]
>Johnmen
>Да. Так можно делать. Если однопользовательская система, мало данных и тормоза по-барабану...:)
Так мы ведь про условия задачи ничего больше не знаем, как только "как избавиться от ошибки"
НУ а мало даных это понятие относительное.
Например при 100000 записей этот алгоритм работает нормально , при
большем не проверял
Да и с многопользовательским режимом не проблема - нужно только
запретить одновременное обновление данных двуми и более юзерами,,
что сделать не такая уж большая проблема
Johnmen (2003-11-21 10:31:00) [3]
>Юрий (21.11.03 10:27)
Да. Так можно делать. Если однопользовательская система, мало данных и тормоза по-барабану...:)
Johnmen (2003-11-21 10:29:00) [4]
>Рамиль © (21.11.03 09:55)
>Так, по моему, вполне нормально, что значения в поле должны быть уникальными
И по-моему нормально. А в чем проблема ?
Юрий (2003-11-21 10:27:00) [5]
По моему все решается тривиально просто (по крайней мере я так делал)
В таблице создается ОДНО поле с уникальным индексом
(обычно автоинкрементное)
Затем при редактирование/добавлении новой записи, перед командой
POST, выполняешь проверку table.locate(....), при помощи которой
проверяешь отсутствие/наличие значения в твоих проверяемых
уникальных полях.
Если locate дает TRUE - сообщение юзеру,мол ты не прав браток.
если FALSE - поехали модифицировать запись.
Конечно все твои "псевдо" уникальные поля должны быть индексированы.
При помощи этого способа можешь держать в своей базе хоть сто
уникальных полей
Вот собственно и все решение проблемы
Zacho (2003-11-21 10:26:00) [6]
> Nikolay M. © (21.11.03 09:53) [16]
Меня бы пристрелили, если бы инвентарные номера нельзя было редактировать. Поскольку поступают они к нам извне, а не генерируются системой, а операторам свойственно ошибаться.
А генерировать их в системе для моей конкретной задачи - нельзя.
Еще пример, который приводил Danilka © - реквизиты физ.лица. Неужели и их нельзя редактировать ? И номер паспорта, например, у тебя генерирует программа ?
Вобщем, уникальные поля - они разные бывают, не только сгенерированные программой, и если оно вводяться вручную - то соответственно и редактировать их можно.
Рамиль (2003-11-21 09:55:00) [7]
>Johnmen
Вот я сейчас сижу программку делаю, таблица со списком дисциплин в школе. Поля ПК и Наименование. Так, по моему, вполне нормально, что значения в поле должны быть уникальными
Johnmen (2003-11-21 09:55:00) [8]
>Zacho © (21.11.03 09:48) [13]
>...по жизни так сложилось :-)
Вот я и думаю, может разобраться в жизни, упорядочить её ?
:-))
Nikolay M. (2003-11-21 09:53:00) [9]
> Zacho © (21.11.03 09:48) [13]
Да, серьезно.
Я за всю жизнь не издевался настолько над юзерами, чтобы заставлять их вводить такую информацию. Генерацию номера счета в банке тоже предложишь руками делать? Да тебя сразу пристрелят.
А зачем нужно редактироватьинвентарные номера? Насколько я в курсе проблемы, за каждым стулом закреплен свой ИН - с какой стати разрешать его вводить руками или редактировать?
Johnmen (2003-11-21 09:52:00) [10]
>Danilka © (21.11.03 09:50)
Ну три поля... А больше ? :)
Danilka (2003-11-21 09:50:00) [11]
[1] Johnmen © (20.11.03 23:41)
>С трудом можно представить такую таблицу, в которой несколько уникальных полей...:)
например, реквизиты физлица - уникальными будут и паспортные данные и ИНН и номер полиса ПФР.
Zacho (2003-11-21 09:48:00) [12]
> Johnmen © (21.11.03 09:39) [12]
Да не на что не намекаю :) Просто странный вопрос "зачем ?" Ну есть несколько ключей, и все тут, по жизни так сложилось :-)
> И, по-моему, ты слишком "в лоб" понял мой пост.
Может быть.
> Nikolay M. © (21.11.03 09:29) [10]
>
> + Еще вопрос - зачем юзеру разрешать редактировать такие
> поля?
Неужели ты это серьезно ? Тогда объясни нашему бухгалтеру, что отныне запрещается редактировать инвентарные и табельные номера и т.д. и т.п. :-)
Johnmen (2003-11-21 09:39:00) [13]
>Zacho © (21.11.03 09:34)
Я не улавливаю, к чему ты клонишь или на что намекаешь...
:)
И, по-моему, ты слишком "в лоб" понял мой пост.
Zacho (2003-11-21 09:34:00) [14]
> Johnmen © (21.11.03 09:12) [9]
> Вот. Рассуждаем дальше. Допускаем, что потенциальный вдруг
> стал реальным.
Что значит реальным ? Есть потенциальные ключи, из них выбирается первичный ключ. И что здесь реальное, а что не реальное ? :-)
> Вопрос - зачем в одной таблице несколько ключей ?
А зачем Солнце восходит на Востоке ? :-)))
Nikolay M. (2003-11-21 09:29:00) [15]
> Johnmen © (21.11.03 09:12) [9]
+ Еще вопрос - зачем юзеру разрешать редактировать такие поля?
Станет в таблице 1 000 000 записей и юзер будет давить на кнопки, пытаясь ввести неуникальное значение среди существующих? Это уже садизм, имхо...
ПС
"Верх упорства - вводить неправильный пароль до тех пор, пока компьютер не согласится".
Johnmen (2003-11-21 09:12:00) [16]
>Zacho © (21.11.03 00:02) [5]
>Просто я придерживаюсь мнения, что любое unique constraint == потенциальный ключ.
Вот. Рассуждаем дальше. Допускаем, что потенциальный вдруг стал реальным. Вопрос - зачем в одной таблице несколько ключей ?
:))
>...таблицы с несколькими уникальными полями: таблица Менделеева ;)
Ну пара полей, ну три, ещё можно объяснить по жизни. Но большее количество...Лично я не могу...
Zacho (2003-11-21 00:57:00) [17]
> Zacho © (21.11.03 00:39) [7]
P.S. Пример конечно корявый и топорный, но иллюстрирует то, что информацию о происхождении ошибки (кстати, в этом примере нет, но можно и искомое автором вопроса имя поля) можно взять из текста сообщения об ошибке.
Zacho (2003-11-21 00:39:00) [18]
> 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;
mfender (2003-11-21 00:32:00) [19]
Я, обычно пишу что-то вроде того:
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:02:00) [20]
> Johnmen © (20.11.03 23:46) [4]
Просто я придерживаюсь мнения, что любое unique constraint==потенциальный ключ. Может, я и не прав.
Кстати, пример таблицы с несколькими уникальными полями: таблица Менделеева ;)
| |
Страницы: 