Как при добавление кодом строки делать проверку на существование такого элемента?
к примеру генерируется у меня в программе случайное число и если такое уже есть то генерировалось ещё одно и записывалось.


поробывал я через тру катч...но во если ошибка вылетает не на повторение, то получается веченый цикл.Код

Сначала запрашивать выборку по указанному критерию. Если возвращён непустой набор данных - значит, запись с таким критерием уже есть.

этот эмм...ужасный способ сам делал...или это приемлемо?

DenWPF, ты полностью сам виноват в том, что получается "ужастик". Незачем было бизнес-логику вытаскивать на клиента.

   а обьяснить?
ну не понимаю я.

Средства SQL-сервера позволяют реализовывать весьма сложную логику обработки данных.
В твоём случае SQL-сервер сам может по запросу генерировать случайное число, проверять наличие такого в таблице, при наличии перегенерировать, пока не получит новое, заносить данные в таблицу и возвращать последнее сгенерированное число. Делается это триггером, пользовательской функцией или хранимой процедурой. А приложение (клиент) просто даёт команду на выполнение запроса и ждёт результата. И не клиента это дело знать, КАК получено случайное число, и сколько времени сервер вкалывал, чтобы его получить.
Иными словами - почитайте хотя бы основы SQL. Скажем вот тут.

DenWPF, также есть специальный тип полей - автоинкрементные, которые могут работать в двух режимах: наращивать +1 каждое новое значение или формировать значение рандомно.

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

Akina, я это прекрасно понимаю по этому и тут и спрашиваю как, кодом я мог и без этого форума.
ок почитаю

Вот запрос который выполниться без ошибки:


one_row - таблица, которая хранит одну запись.

Теперь запрос выполниться без ошибки. Добавилась ли запись можно определить по атрибуту RecordAffected.

Может стоит проверять код ошибки ErrorCode в catch блоке чтоб не обрабатывать другие иксепшены? Думаю этого достаточно будет для решения проблемы.

Смешение бизнеслогики со слоем данных уже морально устарело, модные тенденции архитектуры предлагают разделять приложение на данные, логику и представление.
Чем больше ты свяжешь логику(твой код) с форматом хранения данных (SQL), тем менее гибкой становится разработанная тобой система. К примеру если ты вдруг надумаешь мигрировать на другую SQL СУБД, или вообще перейти на другой формат хранения данных(XML или BigTable), то тебе прийдется полностью переписывать и бизнес слой, поскольку среда хранения данных не сможет обеспечить функционал предыдущей использованной.
Возможность перехода на другой движок БД можно считать очень вероятной... опыт показывает, что желание сменить двиг может появиться очень скоро, а переписывать изза этото все практически с нуля - радужная перспектива...