Проблема с locate

[jenny]

Все работает, только проблема если я выбераю не одну а несколько записей, вставка все равно происходит не смотря на то что в некоторых из выбранных записей дубликат присутствует. Как это исправить, пожалуйста помогите очень надо (если можно без sql запроса)

[ENERGIX]

А не проще поле сделать уникальным, что само по себе сделает невозможным вставку дубликата, далее перехват ошибки при наличии дубликата и все?

[jenny]

Тут не все так просто, здесь на самом деле несколько таблиц задействованы. Я для начала выбираю категорию, к которой относится клиент (Таблица A), a потом переношу запись с таблицы B в таблицу C. Tем самым в таблицы С может быть дубликат, но под разными категориями, то есть в каждой категории client_id уникален, как то так...

[Снег Север]

Такие проблемы обычно означают, что структура таблиц базы неправильная - плохо продумана.

[jenny]

Помоем я просто запрос с Locate не правильный делаю...

[Ism]

Locate всего лишь выставляет нужную запись, он не предназначен для таких вещей
Лучше тогда использовать вместо insert into , replace into

[Снег Север]

Я имел ввиду постоянные переносы/вставки записей из таблицы в таблицу. В правильно спроектированной базе такие операции должны быть редким исключением. Записи вставляются один раз в нужные таблицы с нужными (для последующих выборок) ключами, а потом только update ну и delete.

[Vadim]

Помоем я просто запрос с Locate не правильный делаю...

Нет, у Вас дело совершенно не в Locate. Я Вам в соседней теме уже писал об этом. Видимо Вы ничего не поняли и для того же вопроса, вместо того, чтобы спросить пояснений, открыли новую тему. И здесь, точно так же как и там, решения Вашей задачи опять не будет, т.к. от количества повторений одного и того же вопроса правильный ответ никак не зависит.
Вам правильно говорят: нужен уникальный индекс по тем полям, в которых должно быть дублирования информации. Это сразу же поправит дело.

[jenny]

и как сделать этот уникальный индекс, извините если вопрос глуповат, но вo всем этом я еще не разбираюсь

[Vadim]

jenny
Для этого надо как следует посидеть и подумать.
К примеру, у меня есть список индивидуумов в виде "ФАМИЛИЯ", "ИМЯ", "ОТЧЕСТВО". Во всех подобных списках всегда возникает проблема - а как же нам однозначно определить совершенно конкретного человека? Не секрет, что случаи когда, к примеру, существуют несколько Ивановых Иванов Ивановичей бывает нередки. Как быть? Нужно ввести ещё какое-нибудь поле, которое тоже характеризует человека и позволит определить его уникальность. Пусть это будет дата рождения. Вероятность того, что попадутся люди у которых совпадут все эти четыре параметра довольно низка. Следовательно уникальный индекс мы будем создавать именно по этим четырём полям (примем, что таблица у нас называется "народ"):

Код: Выделить всё

CREATE UNIQUE INDEX [человек] ON [народ] ([фамилия],[имя],[отчество],[дата_рождения] ASC);

Теперь при попытке добавить новую запись (или отредактировать старую), где во всех четырёх полях будут совпадения, сервер баз данных сделать нам это не даст.
Вам нужно:
- определить минимальный список полей, по содержанию которых вы определяете, что запись в таблице дублируется;
- по этому списку создать уникальный индекс (см. пример выше).

[ENERGIX]

Я полностью согласен с Vadim. От себя добавлю только то, что при работе с базами данных - очень важно понимать что должна делать база данных, а что ваша программа. Т.е семечки отделять от шелухи и не допускать ошибок при проектировании схемы-структуры базы данных. Нормализация таблиц, использование триггеров вставки, управление индексами и использование определяемых пользовательских хранимых процедур - все это должна использовать база данных и не пытайтесь все это реализовывать программно. В вашем случае можно использовать и триггер, который выполнит проверку сам, средствами сервера базы.