Текущее время: Пн, авг 04 2025, 07:38

Часовой пояс: UTC + 3 часа


Правила форума


ВНИМАНИЕ!

Вопросы по SAP Query и Quick View - сюда



Начать новую тему Ответить на тему  [ Сообщений: 10 ] 
Автор Сообщение
 Заголовок сообщения: Вопрос по update
СообщениеДобавлено: Пн, дек 03 2007, 17:10 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, янв 16 2007, 19:00
Сообщения: 168
Откуда: город
Имеется таблица в БД: 2 поля ключевых f1 и f2.

Можно ли таким образом изменить значение ключевого поля:
UPDATE dbtab SET f2 = '3' WHERE f1 = '1' f2 = '2' ?

Если это делать нельзя или хотя бы не рекомендуется, поясните, пожалуйста, почему.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 17:48 
Специалист
Специалист

Зарегистрирован:
Чт, мар 22 2007, 14:40
Сообщения: 142
Пол: Мужской
для этих целей вроде бы обычно используют
оператор MODIFY .

но лично я бы лучше сделал,
DELETE
а потом
INSERT

т.к. есть вероятность дублирования ключей и дампа в таком случае.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 17:54 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, янв 16 2007, 19:00
Сообщения: 168
Откуда: город
Pokusannoe_Zubilo написал:
для этих целей вроде бы обычно используют
оператор MODIFY .

но лично я бы лучше сделал,
DELETE
а потом
INSERT

т.к. есть вероятность дублирования ключей и дампа в таком случае.

MODIFY использовать можно, но это будет одно и то же (запись имеется, поэтому будет идти UPDATE).
Про дублирование ключей - есть такой момент. Но если предположить, что перед update делается проверка, чтобы дублирования не происходило, тогда есть ли еще какие-нибудь "противопоказания" на апдейт ключевого поля?


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 18:05 
Директор
Директор
Аватара пользователя

Зарегистрирован:
Ср, сен 22 2004, 08:42
Сообщения: 1079
Откуда: Москва
Пол: Мужской
Open SQl оператор update насколько мне известно в принципе не меняет ключевые поля. Если гарантировано сохранение целостности по первичному ключу и объемы изменений очень велики, то можно использовать native sql.
На 46с вроде нельзя было.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 18:42 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, янв 16 2007, 19:00
Сообщения: 168
Откуда: город
У меня на 4.7 отрабатывает нормально. Но уже стало интересно, что мой код может не отработать на 4.6 и ниже. Тогда это хорошая причина отказаться от этого кода.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 19:35 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, янв 16 2007, 19:00
Сообщения: 168
Откуда: город
Еще возникло предположение, что для некоторых БД этот код не отработает. Ведь, например, при ведении в sm30 тоже нельзя изменить ключевое поле записи. Нужно сначала удалить ее, а затем создать новую. Видимо, в этом все-таки какой-то философский смысл заложен :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Пн, дек 03 2007, 19:35 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, ноя 23 2005, 13:37
Сообщения: 1805
Откуда: ECC 6.0
Пол: Мужской
Тут дело не в версии, а в том, что
Цитата:
The content of primary key fields can only be changed if the respective database table is not linked with a search help and if pool and cluster tables are not accessed. If a link was to be created through the changes and this row would cause double entries in the primary key or a unique secondary index of the database table, no row is changed and sy-subrc is set to 4.


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, дек 04 2007, 14:54 
Модератор
Модератор
Аватара пользователя

Зарегистрирован:
Пт, июн 16 2006, 00:43
Сообщения: 1686
Откуда: Москва <-> Красноярск
Пол: Мужской
Смысл ни разу не философский.
Простая целостность данных, если существуют ключевые связи с другими таблицами. Каскадных обновлений в САПе нема.
Если таблица standalone - то можно и update'ом менять.


Принять этот ответ
Вернуться к началу
 Профиль Отправить email  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, дек 04 2007, 15:56 
Специалист
Специалист
Аватара пользователя

Зарегистрирован:
Вт, янв 16 2007, 19:00
Сообщения: 168
Откуда: город
Спасибо за ответы.

Видимо других предположений почему так делать нельзя уже не будет. Для меня все-таки осталось загадкой, почему апдейт ключевого поля своей таблицы меня заставили переделать на delete + insert. Таблица прозрачная, никаких связей с другими таблицами нет... Меня заверили, что в других базах данных в 9 из 10 случаев будет шорт дамп... бред какой-то.

P.S. Целостность данных и есть философия :)


Принять этот ответ
Вернуться к началу
 Профиль  
 
 Заголовок сообщения:
СообщениеДобавлено: Вт, дек 04 2007, 20:10 
Почетный гуру
Почетный гуру
Аватара пользователя

Зарегистрирован:
Ср, ноя 23 2005, 13:37
Сообщения: 1805
Откуда: ECC 6.0
Пол: Мужской
влад написал(а):
Меня заверили, что в других базах данных в 9 из 10 случаев будет шорт дамп...

Вот это вряд ли. Философия Open SQL такова, что он работает на любых, самых древних, когда-либо поддерживаемых базах данных. И это не пафос, потому что в Open SQL по этой причине отсутствуют тривиальнейшие вещи. И если БД не поддерживает update ключевых полей, то значит SAPовский драйвер этой БД сам заменяет update на delete+insert.


Принять этот ответ
Вернуться к началу
 Профиль  
 
Показать сообщения за:  Поле сортировки  
Начать новую тему Ответить на тему  [ Сообщений: 10 ] 

Часовой пояс: UTC + 3 часа


Кто сейчас на конференции

Сейчас этот форум просматривают: нет зарегистрированных пользователей


Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете добавлять вложения

Найти:
Перейти:  
cron
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
Русская поддержка phpBB