Ошибки в таблицах Paradox

← →
Дмитрий Татарников (2004-02-07 02:26) [0]

Люди! ПОМОГИТЕ! Портятся базы данных. Базы составлены на основе таблиц Parapox. В абсолютно непредсказуемые моменты времени в отдельные таблицы закрадывается некая ошибка. При этом программа продолжает замечательно открывать эти таблицы и сохранять в них данные. Наглядно глюк можно увидеть только при ручном пролистывании таблицы. В Delphi это обычно проявляется в виде бесконечного повторения нескольких строк, а в DatabaseDesktop и в самом Paradox - в остановке и зависании таблицы на какой-то записи. Если таблица в базе данных является подчиненной, то заметить этот глюк можно лишь случайно.
А теперь о главном. Если в такой таблице изменять структуру полей, либо просто попытаться сделать "Pack Table" (не важно: Desktop_ом, Paradox_ом или программно) часть данных таблицы исчезает!!! (иногда просто не дает сделать упаковку). Врукопашную через Paradox исправлять можно, но как сделать, чтобы такая хрень вообще не вылазила? А то заказчиков около 70 и по всем не набегаешься.
Вообще такое происходит не часто, но приносит большие проблемы, т.к. упаковка таблиц и изменеие структуры выполняется программно. В результате, о потерянных данных я узнаю когда "поезд ушел".
Люди добрые! Не дайте погибнуть от рук злых пользователей!

← →
Johnmen (2004-02-07 02:46) [1]

Доп.вопрос : многопользовательский доступ ?

← →
Anatoly Podgoretsky (2004-02-07 12:43) [2]

Злые пользователи тут ни причем, выбран не подходящий формат и наверняка еще и БДЕ не простроено должным образом, плюч неверно написана программа.
Теперь тебе ничего не остатеся как бегать по пользователям и говорить. ну чего вы хотите, данный формат не может хорошо работать в многопользовательской среде, меняйте базу. И тут предлагаешь новую замечательную программу со скидками на апгрейд. Нормальный маркетинговый ход.

← →
td (2004-02-07 13:04) [3]

> Anatoly Podgoretsky © (07.02.04 12:43) [2]

Парадокс не подходит для многопользовательской работы?

← →
Romkin (2004-02-07 13:04) [4]

Сначала его убьют, ибо раньше наверняка говорили, что все замечательно работает :)
Были когда-то программки для устранения подобных глюков, найти, думаю, можно.
Выхода тут два:
0. Переписать логику приложения, чтобы этих глюков не было: ручная блокировка и тд...
1. Отказаться от использования программы в режиме, при котором проявляется глюк
2. Написать новую программу, с использованием нормальной БД, а старую забыть как страшный сон %)
http://www.partmotor.com/psites/delphikmb/csvcfs.htm

← →
Anatoly Podgoretsky (2004-02-07 14:36) [5]

td (07.02.04 13:04) [3]
Подходит, но сложности в настройке и проблемы с разрушением, проблемы увеличиваются с ростом пользоваетелей.

← →
Дмитрий Татарников (2004-02-07 18:32) [6]

> Johnmen © (07.02.04 02:46) [1]
> Доп.вопрос : многопользовательский доступ ?

Программа не многопользовательская. Если точнее, в многопользовательском режиме работают не более 5% моих заказчиков.

> Romkin © (07.02.04 13:04) [4]
> Отказаться от использования программы в режиме, при котором проявляется глюк

Программа использует порядка 30 отдельных таблиц. Такая ошибка проявлялась у разных заказчиков в абсолютно различных таблицах. Я НЕ ЗНАЮ когда это выползает.
Переписать программу проблемотично, т.к. она прошла 6-летнюю эволюцию еще от D2.
А программку по исправлению найти можно, но как диагностировать эту ошибку пока данные на месте. Программа-то не ругается?

← →
mike-d (2004-02-07 20:05) [7]

http://www.rksolution.cz - программа исправления таблиц Paradox
http://www.inprise.com/devsupport/bde/files/tutil32d.zip - DLL для нее
http://www.degisy.com/download.php - DegisyDb - компонент DbChk - почитай readme к нему, может это то что тебе надо...

А вообще послушайся советов выше и потихоньку переводи ее на другой движок

← →
resident007 (2004-02-07 20:38) [8]

...потихоньку переводи ее на другой движок.

Интересно, а на какой движок если к примеру программа сугубо однопользовательская? На IB/Firebird? Или может быть на Oracle -- для одного пользователя ??!!! По моему абсурд из серии искусство ради искусства.

ИМХО, для однопользовательских систем учета, Paradox оптимален, так как:
1. Наиболее легковесен при инсталляции (установка BDE -- 2 дискеты или включить в setup --- и все!)
2. Для однопользовательской БД -- рекордная скорость практически по всем параметрам (помню когда-то по неопытности поставил для локальной програмки IB5 на Pentium 120 RAM 32. После этого сделал версию на Paradox -- все стало летать)
3. Отличная производительность в паре с родным для него BDE -- нет нужды искать альтернативный движок
4. Таблицы Paradox подлежат криптованию, и хотя недобросовестные создатели библиотеки idpdx32.dll для BDE оставили лазейку в виде пары универсальных паролей, существуют коммерческие патчи, закрывающие эту проблему
5. Беспроблемно работает в сетях до 5-7 пользователей, где нет нужды в выделенном сервере, а вполне оптимальным является файл-сервер.
6. Не самое плохое решение для распределенной БД

← →
Romkin (2004-02-07 21:01) [9]

Именно на Firebird, Yaffil, MSDE и подобные.
И что такого, что на одного пользователя? Есть Firebird Embedded
А вот по твоим пунктам:
1. А FB embedded вполне входит на одну дискету, и инсталлировать не надо, просто кинуть пару файлов в папку приложения :Р
2. Ну я бы так не говорил... Ты к нему что, через TTable обращался? Это называется поиздеваться над сервером. Как раз IB5 на P100 32 у меня летал. Тесты не проводил, но субъективно скорость явно не меньше
3. Попробуй Yaffil Personal через IBX, это быстрее :) MSDE точно быстрее, правда, ему и места много надо. И что значит нет нужды? Связка BDE + Paradox ненадежна, сам убедился. При этом есть такая вешь, как хранимые процедуры, что дает еще большую фору в скорости, на клиента идет только выжимка из данных.
4. Вот с криптованием проблемы, но тоже устранимые
5. Сорри, чушь полная. Лет пять назад это было верно, да и то сомнительно, уж слишком трудоемко писать многопользовательские приложения на файл-сервере по сравнению с сервером БД. А сейчас преимущества бесплатных серверов БД просто подавляют.
6. Тут я вообще молчу... Достаточно просто сравнить встроенный сервер и файлы.
Вот только для перевода приложения с файл-сервера на сервер БД надо его полностью переписать, забыв опыт работы с файл-сервером, там совсем другая кухня.

← →
residen007 (2004-02-07 22:08) [10]

Я бы не был столь категоричным. Везде есть свои плюсы и минусы. На какой ширине записи у тебя все летало и сколько записей было?
Со стороны пользователя, по-сравнению с локальными БД, клиент-серверные СУБД не дают никаких преимуществ, а вот для разработчика -- плюсов много. Кроме того Paradox штука капризная, многие заявленные параметры на практике не работают, или работают ненадежно. Иногда портятся заголовки таблиц или сбиваются со счета автоинкрементные поля. По этой причине я отказался от всех механизмов Paradox начиная от ссылочной целостности и заканчивая контролем содержимого полей и умолчаниями. В прикладной программе использую для этих целей только собственноручно написанные функции. Исключения отлавливают все повреждения таблиц и на лету чинят их.

2. Нет, для IB только через Query, а для Paradox -- и то, и другое.
6. Ну и дальше что?

Работают 2 версии программы (firebird/IB и Paradox) для мелких и корпоративных клиентов соответственно, каждая имеет свои преимущества.

← →
Romkin (2004-02-07 23:05) [11]

Вот именно, что Парадокс штука капризная, все ручками.
А ширина записи у меня стандартная, БД же нормализована. Записей, правда, не много было, мегов под сотню-две база.
На стороне пользователя сервер дает одно: надежность. Практически, БД можно обрушить только поломкой оборудования (ну у IB еще когда места нет на диске).
И я вообще не понимаю, как можно перекладывать ссылочную целостность на клиента, чуть что - запускай проверку БД...
Млин... Помню, поставил программу на Парадоксе в подмосковье, так там же электричество в розетке исчезает раза два в неделю. Индексы летят, данные портятся, проверка иногда не помогает...
Кошмар, в общем. Пришлось срочно переносить на IB.
Кстати, если уж пользователю все равно, сервер или нет, то не лучше ли просто взять сервер? И не искать приключений в горе кода для файл-сервера?
Я просто года четыре назад окончательно отказался от файл-сервера в пользу Interbase/Firebird, и вижу только преимущества. У файл-сервера преимуществ перед клиент-сервером уже нет, никаких.
Скорость? Уже компьютер пятилетней давности полностью ее обеспечивает, на типичной БД для одного-пяти пользователей.
Дальше - пожалуйста, ставьте сервер, потянет и пару сотен.

← →
mike-d (2004-02-07 23:23) [12]

> Интересно, а на какой движок если к примеру программа сугубо
> однопользовательская? На IB/Firebird? Или может быть на
> Oracle -- для одного пользователя ??!!! По моему абсурд
> из серии искусство ради искусства.

Зачем же так категорично? Или IB/Firebird/Oracle - единственная альтернатива BDE?
Я к примеру пользуюсь DBISAM - и еще ни разу не пожалел...

← →
residen007 (2004-02-07 23:35) [13]

Да это все понятно, согласен. Просто в Paradox-версии есть пара интересных фишек, удобных для пользователя, но считающихся дурным тоном для полноценного клиент-сервера. Например Table c его двунаправленным курсором позволяет пользователю пролистывать всю базу в обеих направлениях, а также возможность альтернативного ввода информации через DBGrid (основной -- форма). Также локальная Paradox-версия позволяет устроить хранилище резервных копий БД за любое число года (посредством компонента ZipTV), c возможностью восстановления состояния БД за любое число года. Кстати, в локальной сети офиса, в случае Paradox-версии используетя не файл-сервер, а распределенная БД. Недостатки конечно очевидны -- период окна между репликациями, но очевидны и преимущества -- суммарная надежность децентрализованной системы, нет нужды в выделенном сервере,а значит сеть не упадет если он накроется, ну и наконец дешевизна решения, что для малого бизнеса не маловажно.

← →
Romkin (2004-02-08 12:05) [14]

Ну что я могу сказать? Пролистывать всю таблицу в полмиллиона строк, на мой взгляд, дурость. Хотя, конечно, это я могу без проблем устроить. Ну а уж ввод через грид - это совсем просто.
Не надо думать, что это привилегия файл-сервера. Репликация? Это модель портфеля, тоже элементарно.
Дело в том, что я пользуюсь TClientDataset, которая превосходит TTable по всем параметрам, назвать хотя бы сортировку по любому набору полей, в том числе и по вычислимым, возможность работы как с сервером (через провайдер), так и с локальной копией данных... И так далее.
Хранилище резервных копий БД? Созданием архивов? Это действительно смешно, тот же Interbase позволяет создавать резервные копии на лету, во время работы с БД. А простое архивирование данных можно сделать с любыми файлами, это нельзя назвать бекапом.
Если нужна именно репликация - тоже пожалуйста, есть и репликаторы, правда, это уже стоит денег.
Вот поэтому я и говорю, что у файл-сервера нет преимуществ, никаких, его можно сделать похожим на клиент-сервер, но это требует весьма значительных усилий, что того не стоит.

← →
residen007 (2004-02-08 22:38) [15]

В полмиллиона конечно глупость, а тыщ 30 - 50 max, самое то: клиент всегда прав, и что делать, если порой сам не знает что ищет (речь идет о мультилистинговой системе). Так вот если листать такие объемы, Paradox разика в 2,5 бытрее IB будет (самолично тестил), я уже не говорю о времени массовой закачки. При объемах порядка 500 000 скорость IB почти не изменится, а Paradox само-собой ляжет. Ну так кто этого не знает? А оптимум нужен для конкретной задачи.
Назвать полноценной репликацией модель портфеля -- это очень смело, если не нагло. Там еще очень много от ручек зависит (в смысле не портфеля), особенно если БД распределена между несколькими сотнями клиентов в разных регионах. Тут объемы передачи требовалось настолько минимизировать, что передаются даже не записи, а только их изменившиеся поля.
Насчет резервных копий мне взаимно смешно, особенно "IB на лету". Проблема ведь не в том, что без остановки (для моего бизнеса это не критично), а в объемах и скорости копирования, а также в скорости восстановления состояния БД на любую точку года.
IB, это тоже конечно сделает, если помучаться, вот только намного медленнее, так как сложность полновесной СУБД и зависимости тут не в помощь. (Ну не имел же ты в виду тупое копирование *.gdb, что действительно смешно).

← →
Дмитрий Татарников (2004-02-09 00:45) [16]

Господа Мастера! Сравнение плюсов и минусов различных БД - тема, конечно, интересная. Я сам на распутье: какой движок выбрать, если решусь ломать программу. Но все-таки по моему вопросу: переходить на другую систему БД - единственный выход???

← →
residen007 (2004-02-09 01:35) [17]

Инфа о DBISAM меня заинтересовала. Интересно попробовать. Может даст кто-нибудь ссылку для выкачки, а то кроме кряков пока ничего не находится?
Думаю автору ветки это тоже будет интересно.

← →
kaif (2004-02-09 02:44) [18]

Я могу привести ошибку, которую я поймал еще работая с Delphi3, после чего я отказался от Paradox навсегда. Кстати, когда выходили новые версии Delphi или BDE, я прогонял этот свой тест и убеждался, что ошибка эта в ВDE никуда не девается. Она есть даже в Delphi6.
Итак, суть ошибки. Работает 1 юзер:
1. Добавляем запись, пытающуюся нарушить уникальность и вызывающую сообщение о нарушении уникального ключа.
2. Повторяем пункт 1. (не помню, обязателен ли этот шаг)
3. Делаем любой SQL-запрос против этой таблицы. Например, SELECT * FROM MYTABLE.
4. Повторяем пункт 1. Теперь исключительная ситуация почему-то не возникает
5. Закрываем таблицу.
6. Открываем таблицу и получаем сообщение:
"Index is out of date". С таблицей больше работать невозможно. Теперь ее нужно чинить. Как минимум, уничтожать и заново создавать индекс.

← →
residen007 (2004-02-09 04:24) [19]

Есть такое, обходится элементарно: по исключению автоматом перестраивается индекс первичного ключа, перед этим (если есть) грохается ошибочная запись. А теперь о смешном: аналогичное бывает и с IB под BDE, хотя последний по моему был ни причем: иногда со счета сбивался генератор и при inserte возникало аналогичное.

← →
Дмитрий Татарников (2004-02-10 13:14) [20]

Из всего вышеизложенного, я понял, что BDE работает не корректно.
В статье Романа Игнатьева (Romkin) говорится о том, что в транзакции Paradox можно изменять не более 256 записей. С такой ошибкой транзакций тоже встречался. Приходилось дробить их на куски, что замедляло работу.
Также подтверждаю на личном опыте, что сбивается нумерация Autoincrement-поля (если еще и ключ по нему стоит, то новую запись не всунуть).
Если "кончился свет", индексы рушатся. Самое противное, когда рушится первичный индекс. Приходится в программе выполнять автосохранение самих таблиц и при необходимости делать восстановление из резервных копий.
Но это все "видимые" ошибки, которые возможно сразу диагностировать и исправлять. В большинстве случаев все это иправляется программным путем вообще без моего участия. Но есть и такие, которые не диагностируются (то, с чего начинался мой вопрос).
Если все так запущено, то подскажите, на какой более надежный движок можно перейти с наименьшими усилиями (чтобы в корне не ломать программу)?
Пытался найти что-то по DBISAM. Пока только кряки и DBISAM Manager. Может кто подскажет где лежит хотя-бы документация?

← →
mike-d (2004-02-10 23:00) [21]

www.elevatesoft.com

← →
Anatoly Podgoretsky (2004-02-10 23:18) [22]

Дмитрий Татарников (10.02.04 13:14) [20]
Не совсем так, это грехи формата, ну и особенности работы файл-серверных баз.

Ошибки в таблицах Paradox Найти похожие ветки