Объедините первичные ключи - каскадное обновление
Проверьте еще раз путь T1. Эта ошибка часто возникает, когда по этому пути нет файлов. Также убедитесь, что имена верны. Они должны быть такими же, как и раньше. Если вы изменили имя, вы должны также изменить их в файле datasplit. Также убедитесь, что имя файла входного изображения и его основная правда совпадают.
Это некоторые из первых вещей, которые вы должны проверить.
4 ответа
Нет никакого автоматического способа сделать это, но у Вас есть пара опций, можно вручную записать процедуры, или можно или кодировать, генерируют слияние регулярно или динамично генерируют его во времени выполнения. Чтобы сделать это, можно использовать INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS и INFORMATION_SCHEMA.KEY_COLUMN_USAGE и INFORMATION_SCHEMA.TABLE_CONSTRAINTS и INFORMATION_SCHEMA.COLUMNS and INFORMATION_SCHEMA.TABLES создавать процедуру динамично.
Можно также просто перенести всю операцию в транзакцию (хорошая идея так или иначе). Последний шаг должен будет удалить клиента, объединяемого из, поэтому если будет RI на таблице, которую Вы никогда не добавляли, и Вы пытаетесь сделать слияние, то это перестанет работать, потому что Вы не можете удалить клиента, объединяемого, из того, так как существуют зависимые записи в таблице, которая не была уже добавлена к процедуре слияния.
Рассмотрите использование Триггеров вместо этого. На обновлении Клиентов (idCustomer столбец), Вы делаете любые необходимые модификации (Удалите, Обновление...) на связанных таблицах.
Это кажется, что Вы закончите с двумя записями для каждой из этих таблиц, что у обоих есть тот же первичный ключ. Это Ваше намерение?
Customers
idCustomer Company
1 AT&T
2 Cingular
После того, как слияние станет
Customers
idCustomer Company
1 AT&T
1 Cingular
В любом случае самое соответствующее требованиям завтрашнего дня решение состояло бы в том, чтобы записать процедуру. Вы могли передать процедуру оба клиента, и она сделает всю работу обновления всех таблиц по мере необходимости.
Есть ли более свежие решения этой проблемы?
У меня примерно та же проблема, и на данный момент динамическое построение процедур кажется слишком сложным. Вот как это может работать в теории, но я полагаю, что это не так?
В одной транзакции: 1) Временно отключите ограничение первичного ключа для клиентов 2) Обновите первичный идентификатор Cingular до '1', который имеет каскадное правило обновления отношений, которое заботится о дочерних элементах 3) Используйте поле вторичного ключа для удаления (только) Cingular 4) Включите ограничение первичного ключа для клиентов
Ищу ждем чего-то подобного в будущем T-SQL:
УДАЛИТЬ С ОБНОВЛЕНИЕМ idCustomer = 1 FROM Customers WHERE idCustomer = 2;
; -)