ReSQL.ru
     
powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Сохранение уникальности ключа
5 сообщений из 5, страница 1 из 1
Сохранение уникальности ключа
    #33560081
Markuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markuz
Гость
Вот возник такой вопросик. У меня в базе есть специальное поле - ключ уникально идентифицирующий запись. Формируется он с помощью хранимой процедуры по спец.таблице. И его надо обязательно сохранить, т.е. дальнейшие изменения над данным значением запрещены. Просто в программе есть код следующего вида (копирование записи, чтобы не заполнять однотипные строки заново)

Код: plaintext
1.
2.
3.
SCATTER TO la_tek
APPEND BLANK
GATHER FROM la_tek

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

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
FUNCTION rulerecid
	li_recid	= recid
	li_oldvalue = OLDVAL("recid")
	IF(!ISNULL(li_oldvalue)) THEN
		IF(li_oldvalue<>li_recid) THEN
			REPLACE recid WITH li_oldvalue
		ENDIF
	ENDIF
	
	RETURN .T.
ENDFUNC

Насколько это корректно уважаемые гуру.
...
Рейтинг: 0 / 0
22.02.2006, 10:44
| Ответить | Цитировать | Написать  
Сохранение уникальности ключа
    #33560143
GraninDm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
GraninDm
Гость
GATHER FROM la_tel FIELDS EXEPT rerid
...
Рейтинг: 0 / 0
22.02.2006, 11:01
| Ответить | Цитировать | Написать  
Сохранение уникальности ключа
    #33560216
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
Если версия VFP8 или выше, то используй поле типа Integer-AutoIncrement и не мучайся...

Для младших версий, синтаксически корректно. Ошибка в логике. Точнее, в самой идеологии работы с ключевым полем.

Ключевое поле - это такое поле, которое вообще не должен видеть пользователь. В крайнем случае, он может его видеть, но не может редактировать.

Если принять такую идеологию, то возникает закономерный вопрос: а как вообще значение ключевого поля может быть изменено? Только программно! Самим программистом.

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

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


PS: При создании новой записи функция OldVal() вернет значение NULL даже если поле не может принимать значение NULL. В результате, твой код пропустит ситуацию, когда значение ключевого поля было изменено при создании новой записи командой вроде

Код: plaintext
INSERT INTO MyTab (RecID) VALUES ( 10 )

В данном случае функция DEFAULT не сработает, поскольку значение присваивается явно. И код RULE это пропустит, поскольку IsNull(OlDavl(...))=.T.
...
Рейтинг: 0 / 0
22.02.2006, 11:22
| Ответить | Цитировать | Написать  
Сохранение уникальности ключа
    #33560324
Markuz
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Markuz
Гость
Вот посмотрел на код, действительно при

Код: plaintext
1.
2.
SCATTER TO la_tek
INSERT INTO plan_p FROM ARRAY la_tek

Значение по default не выполняется 8( Может в правиле записать проверку на уникальность. Просто код чужой и не я его писал, мне надо только добавить поле-ключ и формировать его. А с помощью default и rule этого добиться быстрее, да и нагляднее, чем просматривать весь код в поисках мест для исправлений.
...
Рейтинг: 0 / 0
22.02.2006, 11:48
| Ответить | Цитировать | Написать  
Сохранение уникальности ключа
    #33560694
Фотография ВладимирМ
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
ВладимирМ
Участник
Для проверки на уникальность просто создай по тому полю индекс типа CANDIDAT. По самой своей природе такой индекс не допускает существование повторяющихся значений.

Только имей в ввиду, что индекс рассматривает вообще все значения, в том числе и в записях, помеченных как удаленные. Разумеется, это можно обойти, если ты укажешь в индексе FOR-условие.

Хотя, лично мне такие индексы (с FOR-условием) не нравятся по той причине, что они не используются в Rushmore-оптимизации. Как следствие, придется создавать 2 индекса: один для контроля уникальности, другой - для оптимизации.

Впрочем, если функция генерации уникального значения не использует коды ранее удаленных записей, то можно обойтись одним индексом CANDIDAT без FOR-условий.
...
Рейтинг: 0 / 0
22.02.2006, 13:21
| Ответить | Цитировать | Написать  
5 сообщений из 5, страница 1 из 1
Форумы / FoxPro, Visual FoxPro [игнор отключен] [закрыт для гостей] / Сохранение уникальности ключа
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение   Полит. конфиден.  
NoSQL.ru       Кролег: Проекты, Новости, Чат       РЕД ФОРУМ       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=41&gotonew=1&tid=1592274]:
 0ms
get settings:
 11ms
get forum list:
 22ms
check forum access:
 2ms
check topic access:
 2ms
track hit:
 63ms
get topic data:
 7ms
get first new msg:
 4ms
get forum data:
 2ms
get page messages:
 38ms
get tp. blocked users:
 1ms
others: 249ms
total:  401ms
созд. / загр.: 401ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]