Открытие базы данных с помощью IBExpert

[alexss1]

Так что я пока буду считать, что проблема в IBExpert.

Можно было все проще и четче описать.

Проблемы возникали по ходу. Но кто ж мог подумать, что IBExpert такое вытворяет. Хотя я с ним вот щас поработал немного, косяки продолжаются. Версия 2009.03.25.
В частности, создал базу, в ней таблицу с 2-мя полями varchar, и решил внести туда данные для проверки. Вобщем занес где-то 20 записей, нажал "подтвердить транзакцию", данные сохранились, затем я взял сделал insert - запись в самое начало, т.е. первую запись внес в начало таблицы. Потом нажал "подтвердить транзакцию" и эта запись у меня переместилась в конец таблицы . Далее я добавил еще такую же запись (таблица без индексов, без ключевых полей) и при попытке удалить одну из этих 2-х одинаковых записей - ошибка что-то типа не могу удалить т.к. есть одинаковые записи. Вобщем как-то не в восторге Может я чего не так делаю - просветите.

[kdv]

Может я чего не так делаю - просветите.

таблиц без первичных ключей не бывает. если и бывают, то это таблицы логов событий.

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

А формальный ответ на вопрос такой - по умолчанию IBExpert показывает "таблицу" запросом с сортировкой (ORDER BY) по столбцу первичного ключа. Потому что без сортировки любая СУБД хранит записи как попало, и выдает как попало. То есть, у множества записей нет ни начала ни конца. И если у запроса нет order by, то элементы множества являются неупорядоченными.
Отсюда: якобы "прыгание" записей, и якобы "проблемы" удаления дубликатов записей.

Так что все-таки, попрошу в проектирование БД. Не на этом форуме, а литературу читать.

[alexss1]

таблиц без первичных ключей не бывает. если и бывают, то это таблицы логов событий.

А что тогда в программе во вкладке "ограничения" - "первичный ключ"? это какой-то другой "первичный ключ", который в таблице не был не создан?

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

Уважаемый, я работал с paradoxовскими базами данных и там не было таких проблем, вот для меня это и ново. У были справочные таблицы, в который не было ключевых полей или это что-то другое по вашему?! Я всего то хочу создать базу данных , занести туда несколько записей и все. И поэтому когда при создании одинаковых 2-х записей я не могу потом удалить одну из них - меня удивляет.

Потому что без сортировки любая СУБД хранит записи как попало, и выдает как попало. То есть, у множества записей нет ни начала ни конца. И если у запроса нет order by, то элементы множества являются неупорядоченными.

Я хочу увидеть записи в этом порядке без сортировки, т.е. в неупорядоченном виде. Это возможно в ibexpert?

[WildSery]

А что тогда в программе во вкладке "ограничения" - "первичный ключ"? это какой-то другой "первичный ключ", который в таблице не был не создан?

Это именно он. И он должен быть, для идентификации записи.

Уважаемый, я работал с paradoxовскими базами данных и там не было таких проблем, вот для меня это и ново.

Нечем тут хвастать. Работал с ламповой радиостанцией, а перешёл на WiMAX.

И поэтому когда при создании одинаковых 2-х записей я не могу потом удалить одну из них - меня удивляет.

Ты вот сам можешь сказать, какую из них ты хочешь удалить? Вот и IBExpert тоже не знает, они для него одинаковые.
А вообще, есть возможность удалять дубликаты по системному идентификатору (см. соответствующую статью на этом сайте, "удаление дубликатов"), и в IBExpert в настройках включается, чтобы он по нему записи идентифицировал (не помню, где конкретно).

Я хочу увидеть записи в этом порядке без сортировки, т.е. в неупорядоченном виде. Это возможно в ibexpert?

Я что-то впервые слышу, чтобы IBExpert самовольно что-то упорядочивал. Дмитрий не совсем корректно выразился, наверное.
Эксперт показывает записи в том виде, как ему отдаёт их сервер, т.е. неупорядочено. А то, что при вставке запись вставляется "под курсор" - это всего лишь особенность реализации датасета+грида, не имеющая к серверу и выборке никакого отношения.
Возможно, кстати, что добавление записи в конце, а не на месте курсора, тоже где-то в настройках рулится.

[alexss1]

А вообще, есть возможность удалять дубликаты по системному идентификатору (см. соответствующую статью на этом сайте, "удаление дубликатов"), и в IBExpert в настройках включается, чтобы он по нему записи идентифицировал (не помню, где конкретно).

Спасибо. На скорую руку не нашел.
Но в качестве тестов уже насоздавал несколько одинаковых записей, т.к. незнал о таких тонкостях, а убить их не могу. При попытке:

Error Message:
----------------------------------------
Invalid token.
Dynamic SQL Error.
SQL error code = -104.
Unexpected end of command - line 2, column 114.

Может подскажете хотя бы как очистить таблицу? Мне бы избавиться от этих записей любым способом. Буду очень благодарен.

Эксперт показывает записи в том виде, как ему отдаёт их сервер, т.е. неупорядочено. А то, что при вставке запись вставляется "под курсор" - это всего лишь особенность реализации датасета+грида, не имеющая к серверу и выборке никакого отношения.
Возможно, кстати, что добавление записи в конце, а не на месте курсора, тоже где-то в настройках рулится.

Фух, ну хоть это радует

И еще раз спасибо за помощь!

[alexss1]

Но в качестве тестов уже насоздавал несколько одинаковых записей, т.к. незнал о таких тонкостях, а убить их не могу.

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

[kdv]

Уважаемый, я работал с paradoxовскими базами данных и там не было таких проблем, вот для меня это и ново. У были справочные таблицы, в который не было ключевых полей или это что-то другое по вашему?!

Позор. Чем Вы бравируете? Тотальным незнанием элементарных правил разработки БД?
В парадоксе, к тому же, достаточно указать ключевое поле, и таблица будет представлять собой кластерный индекс, автоматом сортирующий записи по указанному столбцу. Так что может Вы их и указывали, просто так и не поняли, что это такое.

уже насоздавал несколько одинаковых записей, т.к. незнал о таких тонкостях

каких тонкостях? Это элементарные вещи, которые изучаются в самом начале проектирования БД и создания таблиц.

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

Вы хотите чтобы я Вас забанил за упрямство? Вы считаете себя спецом в проектировании таблиц? Или мне Вам тут прочитать лекцию про первичные ключи? Вы НЕ ЗНАЕТЕ АЗОВ. И начинаете тут троллить, вместо того чтобы научиться. Здесь не курсы, и не обучение новичков прописным истинам. Поэтому настоятельно прошу Вас например прочитать или пройти базовый курс
http://www.intuit.ru/department/database/rdbintro/2/

Я что-то впервые слышу, чтобы IBExpert самовольно что-то упорядочивал.

ищется первичный ключ, потом формируется
Select * from table
order by pk_field
посмотри в мониторе запросов IBExpert.
Это вообще штатное поведение практически любого набора компонент, у которого есть понятие "таблица", когда набор данных открывается кликом по названию таблицы. в BDE так делает IBTable, TTable и т.п. Ну и IBExpert до кучи. Неупорядоченный набор данных мало кого интересует, а автор топика просто напоролся на элементарщину.

[alexss1]

Позор. Чем Вы бравируете? Тотальным незнанием элементарных правил разработки БД?

Вы считаете себя спецом в проектировании таблиц?

Неупорядоченный набор данных мало кого интересует

Вы читаете мои ответы так как вам удобно. Я НЕ считаю себя спецом, я НЕ хвалюсь тем что работал с парадохом. Я создавал таблицу, потом посредством Database Tour открывал ее и вносил изменения. Добавлял туда записи, удалял, одинаковые, разные. У меня были таблицы c ключами, индексами, но были и без. Называйте их как хотите - справочными, таблицами логов событий, я НЕ создавал первичного ключа, мне НЕ нужна была сортировка. В них было порядка 10-20 записей.
Теперь я просто решил попробовать сделать ТОЖЕ САМОЕ в ibexpert, я создал тестовую таблицу с парочкой полей, нашел вкладку "данные" и внес туда записи, оказалось что одинаковые. Потом, когда увидел - решил удалить - но уже было поздно. С помощью Database Tour я удалял в аналогичной таблице, здесь не смог. Точка.

Так что может Вы их и указывали, просто так и не поняли, что это такое.

Успокойтесь, там где нужно - ключи я создавал командами в RADе, так и с помощью того же Database Tour и прекрасно знаю для чего они нужны.

[WildSery]

ищется первичный ключ, потом формируется
Select * from table
order by pk_field

Хм. Действительно. Но не ясно нафига.

[kdv]

я НЕ создавал первичного ключа, мне НЕ нужна была сортировка. В них было порядка 10-20 записей.

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

Успокойтесь, там где нужно - ключи я создавал командами в RADе, так и с помощью того же Database Tour и прекрасно знаю для чего они нужны.

Если Вы прекрасно знаете что такое ПК, то

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

б) о чем вообще мы тут разговариваем, про разный "порядок" записей?

[kdv]

Хм. Действительно. Но не ясно нафига.

ну как нафига. принято так. у 99.999% таблиц есть ПК. Он идентификатор. Значит если мы пишем не запрос, а тыкаем "открыть таблицу", неплохо бы ее показать упорядоченной именно по идентификатору (ПК).

[alexss1]

справочник в котором нельзя отличить справочные записи друг от друга.

Ну ладно, но хотя бы удалить то я мог эти записи, а здесь не могу. Почему тогда ibexpert мне "дал возможность" создать одинаковые записи, должна же быть превентивная защита. Я вообще случайно, если на то пошло, их создал, в момент "тупого" набора записей - ведь это был просто тест.

[WildSery]

ну как нафига. принято так. у 99.999% таблиц есть ПК. Он идентификатор. Значит если мы пишем не запрос, а тыкаем "открыть таблицу", неплохо бы ее показать упорядоченной именно по идентификатору (ПК).

Но это дело сервера! Зачем order by писать-то?
Попахивает M$ - там кое-где тоже, если выбрали некий набор без сортировки, то на всякий случай по первому столбцу отсортируем.

[Dimitry Sibiryakov]

Ну ладно, но хотя бы удалить то я мог эти записи, а здесь не могу.

Почему не можешь? Можешь. Но для этого придётся закрыть вкладку оглуплятора с её неестественным интеллектом, а вместо неё открыть SQL Editor и руками (о ужас!) набрать в нём SQL запрос на удаление этой записи.

Может, для "парадоксальных" людей это и странно, но работа с SQL сервером осуществляется с помощью SQL запросов...

[kdv]

Почему тогда ibexpert мне "дал возможность" создать одинаковые записи, должна же быть превентивная защита.

превентивная защита против чего? ты же ПК не создал! Раз нет ограничений по уникальности, то никто не запрещает хоть миллион одинаковых записей создать.
Мы опять возвращаемся к тому, что Вам в срочном порядке требуется ликбез.

[Attid]

Но это дело сервера! Зачем order by писать-то?

считается что так удобнее. кем и когда вопрос к Хвастунову.
это дело в настройках где-то отключается.

[kdv]

Но это дело сервера! Зачем order by писать-то?

дело сервера что - показать в гуе список таблиц, и по клику на таблице показать в ней данные? Сергей, ты очумел
Прими как данность, что ЛЮБОЙ (99%) инструмент, который имеет функциональность мышеклика по списку таблиц с показом данных без ручного написания запросов, по умолчанию открывает таблицу с order by по ПК.
Лучше попробуй найти инструмент, который так не делает.

[alexss1]

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

давайте нахрен уберем этот визуальный редактор и будем все делать SQL Editor-е. Но если есть эта "вкладка оглуплятора" и я могу внести записи с ее помощью, но не могу их удалить с ее помощью, то я тогда не знаю.

[hvlad]

Ну ладно, но хотя бы удалить то я мог эти записи, а здесь не могу.

Учи SQL. Умоляю...

[kdv]

и я могу внести записи с ее помощью, но не могу их удалить с ее помощью, то я тогда не знаю.

да все очень просто. у Грида есть понятие "текущая запись". И такое понятие легко траслируется на файл-серверные движки типа парадокса и ДБФ в "номер записи". Но не транслируется на SQL, потому что там такого понятия нет. Есть множество записей.

Дальше. Стандартная обработка, например при удалении или обновлении текущей и одной записи в гриде, раз нет первичного ключа, конструирует запрос типа

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

delete from table
where field1 = ... and field2 = .. and field3 = ...

но что самое главное, поскольку мы в гриде стоим на одной записи, то и предполагается, что удалена будет одна. Это специально проверяется через вызов RowsAffected после выполнения оператора. И когда обнаруживается, что RowsAffected > 1, то соответственно датасет матерится, что хотели удалить "текущую", а их оказалось на самом деле не одна, а несколько. (если RowsAffected = 0 идет сообщение что запись отсутствует или уже удалена).
Вот если бы у этой таблицы был первичный ключ, тогда бы в оператор удаления попало условие по первичному ключу (where pk_field = ...), а в этом случае дубликатов записей принципиально быть не может.

В общем, это опять та же самая элементарщина при "навигационной" работе с SQL-серверами. Так что на время работы с SQL можете выкинуть из головы все что Вы знали о работе с Paradox.