Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

BDE. Ошибка с SQL и уникальным индексом [D5, D7, Paradox]


Страницы:   1 2

-=Guest=- ©   (2003-05-05 21:24:00) 

Есть таблица Paradox.
Поля ID, ID1, ID2 - все Long Integer
ID - первичный ключ.
По полям ID1 и ID2 есть уникальный индекс.

Добавляю значения 1,1,1
Затем используя TTable пытаюсь добавить 2,1,1 - естественно "Key violuation"

Но беру TQuery и делаю "Insert Into "MyTable.db" Values(2,1,1)"

Добавило !!!

После этого и TTable и TQuery может вводить любые дублирующиеся записи(типа 3,1,1 4,1,1 и т.д.), а если сделать переиндыксацию таблицы - то мой уникальный индекс вообще удаляется, как будто его и не было.

Проверил на трех машинах Win98-D5 и WinXp-D7

Для работы с таблицей использовал Database Explorer(из RxLib Demo) и SQL Explorer из Delphi.
Таблица создавалась в Database Desktop.


Dred2k   (2003-05-05 23:46:00) [21]


> -=Guest=- (05.05.03 23:15)

Да нет, вариантов не будет. Вот сейчас тоже спать пойду - только логи забэкаплю от пары сервачков (типа приложений) и агента статистики. Тоже самое: десятки тыщ записей, постоянное обновление, сеть, ключи, уникальные индексы, TQuery (иногда TTable c CachedUpdates) и гвоздь программы - "Paradox - да и только" (ясный перец - недостойный внимания "небольших супермонстров"). И уже больше двух лет пашет в слегка обновляемой версии (для поддержки)...
(сладко зевая) Спокойной ночи! ;)


-=Guest=-   (2003-05-05 23:15:00) [22]

Ты все таки посмотри. Я выходные просидел за перебиранием кода - думал что чето замутил, ведь не должно быть такого. Проверял на трех машинах под разными осями и делфами. Или ты думаешь мы тут в писочнице играем и по каждой мелочи в форум лезем. Все проверено и перепроверено. Иду спать, 14-й час за компом. До завтра.
Будут варианты - пиши.


Dred2k   (2003-05-05 23:03:00) [23]


> -=Guest=- (05.05.03 22:52)
> тебе "надо посмотреть"

Это по-любому смотреть надо, и тебе - в первую очередь. Если все так, как тобой описано - случай неадекватный, эт точно. Предположить на ходу сколь-нибудь реальное объяснение не могу - _такой_ ситуации не возникало (были похожие траблы, но все заканчивалось порченной, т.е. упавшей, таблицей - по индексам опять же, но такая нормально не откроется в TTable, TQuery тоже скажет об "index corrupted").
MsGuns кудряво так все описал, что я куплю себе учебник по софистике... Для начинающего.


-=Guest=-   (2003-05-05 22:52:00) [24]

тебе "надо посмотреть"


Dred2k   (2003-05-05 22:35:00) [25]


> MsGuns © (05.05.03 21:45)

Говоришь ты абсолютную лажу. Если б было так, то BDE вообще не вышел бы на рынок - зачем, при такой-то тупорылой несостоятельности...
Никаких аргументов далее не будет - просто возьми и попробуй, тогда можно будет обсудить.
(а то встречаю, порой, от любителей серверов такое, что просто и вдруг ставит жирный крест на всей повседневной рутинной работе систем DBISAM, в т.ч. и парадокса, которую я имею счастье наблюдать ежедневно - работа надежная и полезная, при грамотном использовании, правда).
Короче, не грузи. А то одна реклама "сникерсов" + немного псевдонаучных гаданий...
(у товарища либо индекс слетел во время бурных экспериментов, либо "надо посмотреть"...)


-=Guest=-   (2003-05-05 22:32:00) [26]

Жар-птица вне конкуренции, однозначно надежнее, но быстрее ли(как локальная БД). Приложение то уже написано и юзается. С другой стороны стремно если вдруг все полетит и отхватить люлей. Но без опыта работы на FireBird тоже переходить не очень класно.


MsGuns   (2003-05-05 22:29:00) [27]

По поводу Locate.
Одна из славных черт парадокса - быстрота обслуживания курсора (через BDE). Т.е. скачки по НД размером в несколько сот и даже тысяч записей выполняются существенно быстрее (для TTable), чем даже во многих серверных технологиях. "Тормоза" у тебя не от этого, а по-видимому, от того, что при скакании по НД ты не отключаешь отображение. Делай так:

Grid1.DataSource.Enable := false;
Table1.Locate...
все что вздумается, пока не надоест
Grid1.DataSource.Enable := true;

и почувствуй разницу !




MsGuns   (2003-05-05 22:23:00) [28]

Если все же полюбляешь парадокс, то и в нем можно эффективно работать с индексами, помня, однако, ЧТО ИНДЕКСЫ - ЕСТЬ ВСЕГО ЛИШЬ ДОПОЛНИТЕЛЬНОЕ ЛОГИЧЕСКОЕ СРЕДСТВО для повышения эффективности доступа к таблицам и применяются ЛОКАЛЬНО, т.е. в том приложении, которое их активизирует. Из этого следует, что если надо обеспечить уникальность значений совокупности некоторых
НЕКЛЮЧЕВЫХ (PK) полей таблиц, то:
- Не проработана как следует топология БД (структуры таблиц, ключи, связи, разбиение инфы по таблицам - нормализация и т.д.)
- Обеспечить программно защиту от появления в таблице "дублей"
(например перед постом давать запрос "левым" TQuery и смотреть рез-т)
- Перейти на трехзвенку, где можно централизовать всю логику работы с БД и не зависеть от "прихоти" клиентов-приложений.


MsGuns   (2003-05-05 22:14:00) [29]

САМЫЙ ЛУЧШИЙ ВАРИАНТ - это кинуть парадокс и взять НОРМАЛЬНЫЙ СЕРВЕР. Например, Firebird (клон IB). Бесплатен, легок, шустр, надежен.
И дело даже не в том, многопользовательская БД или нет. Хотя бы в том, что мнлжество логики можно легко и просто делать в метаданных непосредственно на сервере в БД. Полнофункциональная поддержка транзакций (имеется в виде не операция на ОДНОЙ таблице, а логическая цепочка последовательных изменений во многих таблицах). Забудешь про слеты индексов, "Table is busy", lck и т.д.


-=Guest=-   (2003-05-05 22:13:00) [30]

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


-=Guest=-   (2003-05-05 22:02:00) [31]

Возможно, но если сделать уникальный индекс по одному полю (напр. ID1), то SQL проверяет дублирование и выдает "key violuation", а если сделать уникальный индекс по двум полям - то происходит описанное выше. Почему так.

Спасибо за ответ,MsGuns ©.
А какой выход. Сейчас проверяю Locate"ом - но это заметно медленнее, чем если бы велась проверка на уровне BDE. Изпользовать TTable невозможно - запрос из нескольких таблиц, результат которого правится в Grid"e как в Excel. Заметны тормоза при переходе со строки на строку. На SQLServer переходить тоже нет смысла - там один пользователь.
Может есть варианты. Подскажите.


MsGuns   (2003-05-05 21:45:00) [32]

Нет никакой ошибки - все АБСОЛЮТНО КОРРЕКТНО с точки зрения лок.БД и парадокс в частности.

>Затем используя TTable пытаюсь добавить 2,1,1 - естественно "Key violuation"

Конечно, естественно - ведь индекс у тебя активный ? Вот BDE ПЕРЕД физ.вставкой сделала поиск по активному индексу, нашла повтор и "вытолкнула" запись

>Но беру TQuery и делаю "Insert Into "MyTable.db" Values(2,1,1)"
Добавило

И тоже естественно. Для запроса BDE не держит кэш активных индексов (ведь у тебя нет RequestLive и вообще выполняется метод ExecSQL, а не Open) и, след-но, не делает проверки ПЕРЕД добавлением. Т.к. PK новой записи уникален, то она спокойно добавляется.

Парадокс - это не Сервер, который в соответствии с заданными в самой БД метаданными правилами НЕЗАВИСИМО ОТ ИСТОЧНИКА И СПОСОБА запроса осуществляет ОБЩИЙ для всех контроль данных во всех таблицах БД.



Страницы:   1 2

Наверх

Титульная страница Поиск, карта сайта Написать письмо