Форум: "Базы";
Текущий архив: 2003.01.09;
Скачать: [xml.tar.bz2];
Вниз
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]Всем огромнейшее спасибо! Проблему решил созданием другой базы и перекачиванием полезных позиций в нее из старой. Теперь бъюсь над локализацией первопричины глюков.
Страницы: 1 вся ветка
Форум: "Базы";
Текущий архив: 2003.01.09;
Скачать: [xml.tar.bz2];
Память: 0.49 MB
Время: 0.008 c
