Multiple records found but only one expected...

← →
ramil (2002-12-14 16:24) [0]

В какой-то момент времени в таблице базы возникают записи "двойники", и при обращении к таким возникает подобная ошибка. Как убрать эти записи? При попытке удалить пишет то-же. Т.е. база частично парализована. Про причину появления пока не спрашиваю, покапаюсь чуток, может сам что сморозил...А так, если не обращаться к дублированным записям, все работает. КАК БЫТЬ?

← →
Anatoly Podgoretsky (2002-12-14 16:41) [1]

Ты хочешь что бы указили ошибку в твоих запросах без самих запросов, лестно конечно.

← →
ramil (2002-12-14 17:36) [2]

Дело то не в запросах, если даже пользоваться DatabaseDesktop можно увидеть эти двойные записи в таблице, и при попытке удалить появится похожая надпись в нижней строке состояния. Т.е. 1) то что база подпорчена это уже факт, 2)я бы на данный момент был бы удовлетворен если бы каким-то образом удалось удалить эти двойные записи из таблицы. Спасибо.

← →
Reindeer Moss Eater (2002-12-14 17:41) [3]

Двойных записей в IB не бывает. Если конечно есть первичные ключи в таблицах.

← →
ramil (2002-12-14 17:45) [4]

Вот те на! Дальше и спросить не знаю как...

← →
Reindeer Moss Eater (2002-12-14 17:49) [5]

Спроси у своего сервера, создавал ли ты первичные ключи для таблиц.

← →
Anatoly Podgoretsky (2002-12-14 17:51) [6]

Ты что, хоть все записи одной срокой, вжик и нету

← →
ЮЮ (2002-12-15 02:55) [7]

>я бы на данный момент был бы удовлетворен если бы каким-то образом удалось удалить эти двойные записи из таблицы. Спасибо

Delete from table1 where ...

Оператору DELETE, в отличии от UPDATE, всё равно сколько записей удовлетворяет условию

← →
Reindeer Moss Eater (2002-12-15 08:34) [8]

UPDATE"у тоже по барабану сколько записей он изменит.

← →
ЮЮ (2002-12-15 11:16) [9]

>UPDATE"у тоже по барабану сколько записей он изменит.
Если этот UPDATE не в TUpdateSQL, явном или неявном, к в данном случае.

← →
Anatoly Podgoretsky (2002-12-15 11:32) [10]

За все это время автор так и не догадался привести свои запросу, структуру, ну как будто ветка потрепаться.

← →
ramil (2002-12-15 13:54) [11]

Конкретизирую вопрос (не знаю насколько достаточно).Есть база IB Sclad.gdb, содержащая в себе 17 таблиц. У одной из них "ZAKAZ" следущая структура, приведу эту часть оператора SQL:
...
Create Table Zakaz(ZakazNo Integer,TovarName Char(20),RasDat Date, Price Integer, Count Integer);
...
Уникальные ключи не определены(ни в одной таблице), есть лишь индексы.
Теперь просматривая эту таблицу (модернизированную уже моей программой в течение 0.5 года) через Database Desktop (чтоб не приплетать мою программу) обнаруживаю одинаковые записи (штук -осемь) - во всех столбцах нулевые значения, а вместо даты 0:00:00; 30:12:1899
И при попытке удалить их через Ctrl-Del, предварительно переведя тут же таблицу в режим редактирования,получаю надпись в строке состояния - Multiple records found, but only one was expected и естественно ничего не удаляет, а с нормальными записями этот номер проходит влегкую. Ну и, соответственно, моя программа реагирует на подобные попытки соответствующе.

← →
Reindeer Moss Eater (2002-12-15 13:57) [12]

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

← →
Reindeer Moss Eater (2002-12-15 14:02) [13]

alter table Zakaz add constraint pk_Zakaz primary key(список_полей_таблицы_Zakaz_через_запятую_уникально_идентифицирующих_запись);

← →
Alpine (2002-12-15 14:11) [14]

А такой запрос не помогает ?
Select distinct * from tablename

← →
Reindeer Moss Eater (2002-12-15 14:18) [15]

>Alpine ©
А кто его в DatabaseDesktop сформирует?
Да еще чтобы он "живым" оказался (для CTRL+DEL)?

← →
Anatoly Podgoretsky (2002-12-15 14:19) [16]

ramil (15.12.02 13:54)
Вот по этому у тебя все неприятности и возникают, влзможно поле ZakazNo у тебя естественный первичный ключ, если нет, то как указал Reindeer Moss Eater (15.12.02 14:02) сделай искуственный, автоинкриментный, в IB это через генераторы

← →
passm (2002-12-15 15:44) [17]

Anatoly Podgoretsky © (15.12.02 14:19)> Скорее всего сначала придется создать поле INTEGER, затем заполнить его уникальными значениями, и потом создать по нему уникальный индекс.
Но, глядя на таблицу, под ключевые поля напрашиваются ZAKAZNO, TOVARNAME. Кстати, не лучше ли было ввести товарный справочник?

← →
ramil (2002-12-15 17:49) [18]

Всем большое спасибо (за терпение в первую очередь).
Про решение проблемы в корне - это что придется в каждую таблицу (17 шт.) искусственное поле засовывать и определять по нему ключ (по уму то как делают? это ж насколько вырастет объем базы?)
>Но, глядя на таблицу, под ключевые поля напрашиваются ZAKAZNO, TOVARNAME. Кстати, не лучше ли было ввести товарный справочник?
В том-то и дело, что все значения остальных полей не уникальны и могут встречаться в таблице в разных комбинациях, и так почти во всей базе (12 из 17 таблиц точнее).
Спасибо.

← →
passm (2002-12-15 17:55) [19]

ramil (15.12.02 17:49)> Сложно ли будет пересоздать таблицы и занести в них правильные данные?

← →
Anatoly Podgoretsky (2002-12-15 18:11) [20]

ramil (15.12.02 17:49)
На размер не стоит обращать внимание, дкмать надо над работсопсобностью таблиц

← →
ramil (2002-12-15 18:25) [21]

> passm © (15.12.02 17:55)
> ramil (15.12.02 17:49)> Сложно ли будет пересоздать таблицы
> и занести в них правильные данные?

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

← →
ЮЮ (2002-12-16 05:20) [22]

C записями-паразитками справился?
Delete from Zakaz where (RasDat=0) or (RasDat is NULL)
Только не из Database Desktop-а, а хотя бы из SQL Explorer-а

← →
ramil (2002-12-16 15:32) [23]

Всем огромнейшее спасибо! Проблему решил созданием другой базы и перекачиванием полезных позиций в нее из старой. Теперь бъюсь над локализацией первопричины глюков.

Multiple records found but only one expected... Найти похожие ветки