![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
BDE. Ошибка с SQL и уникальным индексом [D5, D7, Paradox]
-=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 новой записи уникален, то она спокойно добавляется.
Парадокс - это не Сервер, который в соответствии с заданными в самой БД метаданными правилами НЕЗАВИСИМО ОТ ИСТОЧНИКА И СПОСОБА запроса осуществляет ОБЩИЙ для всех контроль данных во всех таблицах БД.