Есть работающий уже 7 лет проект на Paradox (около 50 таблиц общий объем 100 МБ)
Его нужно перевести в Interbase или Firebird.
Я сделал DataPump базы данных и создал простое приложение для просмотра таблиц уже в IB. Но в старом проекте есть очень много процедур для обработки данных, с которымы возникают сложности.

Книжка пишет, что процедурs типа While not table eof do ... использовать неправильно, нужно пользоваться хранимыми процедурами и запросами. Тоже самое с обработчиками событий типа OnBeforeInsert, OnAfterPost и аналогичными, которые нужно переводить в тригеры.

Есть ли какие-нибудь примеры или методики как это лучше сделать? А то некоторые процедуры старого проекта состоят из нескольких десятков или сотен строк кода и я пока без понятия как их загнать на сервер.  

И будет ли очень плохо, если некоторые из процедур While not table eof do... оставить "как есть" ?

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

> Есть работающий уже 7 лет проект на Paradox

Не три, не чеши - само пройдет.

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

> Его нужно перевести в Interbase или Firebird.


В таком случае без раздумий - Firebird!


> Есть ли какие-нибудь примеры или методики как это лучше
> сделать? А то некоторые процедуры старого проекта состоят
> из нескольких десятков или сотен строк кода и я пока без
> понятия как их загнать на сервер.  


Пойти можно двумя путями:

1. Оставить все как есть (все while not и прочее), добиться того, чтобы все работало хотябы как раньше (производительность может в некоторых случаях ухудшиться, главное - не нарушить логику). Затем выявить те места, для которых необходима оптимизация, и их уже прорабатывать (хранимыми процедурами, более мощными и быстрыми запросами и прочими возможностями, предоставляемыми сервером СУБД)

2. Переписать все заново. Вероятно, это займет гораздо больше времени, чем 1, зато освежит память по всему проекту в целом :)

> В таком случае без раздумий - Firebird!

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

> [5] BUM   (08.07.08 10:31)

0/1 не подойдет?

> 0/1 не подойдет?

Т. е. запрос вида (которых в проге немерено) Select * From .. Where FL = True прокатит при значениях 0, 1? Чтото сомнительно

> [7] BUM   (08.07.08 10:45)

Никто и не гарантировал полной совместимости между разными СУБД.

> BUM  (08.07.2008 10:31:05)  [5]

> А как другие выходят из такой ситуации?

Выбором соответствующей СУБД до использования, а не после.

> PEAKTOP ©   (07.07.08 16:37) [2]
> Не три, не чеши - само пройдет.

в общем случае не пройдет, но учитывая

>  (около 50 таблиц общий объем 100 МБ)

при примероно постоянном кол-ве юзеров точно чесаться само перестанет.

Но: возможно, за почесать человеку неплохие для него деньги обещают :)

> Petr V. Abramov ©   (09.07.08 00:40) [10]

Интересно, как уважаемые знатоки посоветуют защитить сетевую базу на парадоксе от несанкционированного просмотра и изменения?

> nemirof ©   (09.07.08 01:06) [11]
>
>
> > Petr V. Abramov ©   (09.07.08 00:40) [10]
>
> Интересно, как уважаемые знатоки посоветуют защитить сетевую
> базу на парадоксе от несанкционированного просмотра и изменения?
>
>

Дык никак.
Парадокс на это не расчитан.
Более того, он и как локальная база не имеет защиту от "несанкционированного просмотра и изменения".
Да и вообще. Парадокс как сетевая база - это нонсекс!
:) Очепятка моя.

> Более того, он и как локальная база не имеет защиту от "несанкционированн
> ого просмотра и изменения".


Зато в нем можно защитить таблицу с помощью пароля. И попробуй открой! :)


> Парадокс как сетевая база - это нонсекс!


Типа это круто? :)

> В таком случае без раздумий - Firebird!

На нескольких десятках пользователей ему поплохеет.

Я бы посоветовал оракл, но чтобы переделывать поменьше и поэтапно, не теряя работоспособности, лучше взять мс скл. Он наиболее похож по типам данных на парадокс.

> На нескольких десятках пользователей ему поплохеет.


Да ну? С чего бы?

> Loginov Dmitry  (09.07.2008 7:50:13)  [13]

Неужели ты веришь в сказки для ламеров, да даже и ламеры Элементарно открывают.

> ANB  (09.07.2008 10:06:14)  [14]

В Парадокс настолько мало типов, что он похож на любую базу.

> На нескольких десятках пользователей ему поплохеет.

поставить субд на колени можно и одним юзером
все зависит от того, какие запросы, как часто
ну и от эффективности проектирования БД
и в последнюю очередь от железяки версера и сети

>Loginov Dmitry ©   (07.07.08 22:38) [4]

Поддерживаю практически без ремарок. Но с одним дополнением.
Если перевод один-в-один не получается (например из-за несоответствия типов данных), то
можно пойти на таку хитрость (правда для TTable это не прокатит) - таблицы в ИБ назвать иначе, чем в парадоксе, а именами пападоксовксих таблиц назвать процедуры или вьюхи, в которых представлять данные "как в парадоксе". Это если максимально выносить логику на сторону сервера

Что касается самого парадокса, то сказки про его несостоятельность как многопользовательской СУБД, которые тут любит рассказывать компания во главе с Германом - это всего-навсего следствия их личного печального опыта, не более.