Мастера DELPHI (документация, исходники, скачать)

Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

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

На что сменить ГЛЮЧНЫЙ Paradox?

Страницы: 1 2 3 4 >
KIR © (2002-09-12 02:16:00)
Есть база (уже довольно большая) на Paradox"e. К ней имеется клиент. Paradox своими глюками откровенно задолбал. Народ, на что посоветуете перенести БД? Естественно, хочется сделать минимальные изменения в клиенте. А если возможно, то вообще их не делать.
Заранее спасибо за дельные советы!

Romkin (2002-09-16 12:08:00) [1]
Ну да... попробуйте открыть таблицу записей эдак 10000 в TTable & TQuery, и посмотрите разницу. TTable всегда пытается тянуть индексы, да и автоматическая работа с запросами просто на высоте, иногда вполне может перечитывать всю таблицу после правки одной записи. Так что только TQuery - для сервера, TTable - для файловой базы
Вообще-то действительно, лучше сразу client/server, чтобы потом не переделывать, я сам давно уже отказался от локальных таблиц

Alex Marmuzevich (2002-09-16 11:16:00) [2]
Почему собственно "TTable вообще не надо использовать для баз Client/Server". Я как-то не читал у Borland ограничений. Да и по-моему, уж лучше TTable, чем RequestLive = true. Кроме того, для ODBC баз что TTable, что TQuery используют единый механизм доступа к данным.

int64 (2002-09-16 04:19:00) [3]
Моё имхо, любую серьёзную базу сразу писать как клиент/сервер; ресурсы нынешних компьютеров это позволяют. Даже если она всегда будет локальной.
По крайней мере, это меньше извращение, чем из локальной лепить сетевую. (Постоянно вижу такое чудо из FoxPro).

Anatoly Podgoretsky (2002-09-16 00:27:00) [4]
Так Visual FoxPro или дельфи с Visual FoxPro таблицами

Mike13 (2002-09-16 00:06:00) [5]
а никто тут Visual FoxPro не пробовал? работает с данными побыстрее любого Access"a

Peter Gluhiy (2002-09-15 17:21:00) [6]
> evgeg © (14.09.02 23:30)
TTable к базам Client/Server обращается через SQL-запросы!
Или вы думаете что напрямую к файлу БД?

Hro (2002-09-15 00:40:00) [7]
Я вообще не пойму, что трудно TTabe заменить на TQuery с Select * from Table1 ?

evgeg (2002-09-14 23:30:00) [8]
> Alex Marmuzevich (14.09.02 16:04)

TTable вообще не надо использовать для баз Client/Server.

Polevi (2002-09-14 17:17:00) [9]
>Alex Marmuzevich (14.09.02 16:04)
вы в суд на майкрософт подадите, они вам денег заплатят за моральный ущерб

Alex Marmuzevich (2002-09-14 16:04:00) [10]
>Погано - это как?!! Может я что-то не так делаю? Может я записи >не так добавляю? О чем речь?!
Сделай форму TTable + TDataSource + TDBGrid.
Открой таблицу с автоинкрементным полем. Добавь строку, свведи данные и сохрани. Без Refresh в виде Close->Open будет очень интересно таблица отображаться.
Если повторить аналогичную процедуру с Paradox таблицей - все отлично

ShooRoop (2002-09-13 12:00:00) [11]
MSSQL - идеальная субда, у меня база полтора гига, порядка 40 активно работающих с ней пользователей, живет 2 года без ЕДИНОГО глюка. Стоит своих денег, 100/16.

KSergey (2002-09-13 11:16:00) [12]

> 2. Замену на MSSQL не рекомендую, так как погано таблицы
> работают при добавлении.

Погано - это как?!! Может я что-то не так делаю? Может я записи не так добавляю? О чем речь?!

Polevi (2002-09-13 10:45:00) [13]
>Alex Marmuzevich (12.09.02 21:16)
У меня есть база Access - 70 метров с ней работают 30 человек и представьте себе только тем и занимаются что добавляют записи. И ничего никуда не валиться. Если сделано криво будет валиться на чем угодно.

Val (2002-09-13 10:28:00) [14]
>Виталий Панасенко (13.09.02 09:02)
зато значением генератора можно оперировать.

Виталий Панасенко (2002-09-13 09:02:00) [15]
>evgeg © (12.09.02 21:37)
> отсутствие автоинкрементных полей (хотя проблема и решалась >триггерами с генераторами).

>Тригер+генератор гораздо лучше автоинкрементного поля.

автоинкремент проще обьявить и использу, а тут нужно еще и триггер рисовать, хотя мне нравится и то, и это

evgeg (2002-09-12 21:37:00) [16]
> отсутствие автоинкрементных полей (хотя проблема и решалась триггерами с генераторами).

Тригер+генератор гораздо лучше автоинкрементного поля.

Alex Marmuzevich (2002-09-12 21:16:00) [17]
Занющим посвящается:
1. Я рекомендовал не MSSQL а MySQL, так как
- абсолютно бесплатно
- легко работает
- типы данных практически соответствуют Paradox,
- хорошо работает через ODBC
- есть свободные компоненты, по функциональности идентичные TTable
2. Замену на MSSQL не рекомендую, так как погано таблицы работают при добавлении. Кроме того, сомнения берут в бесплатности. + Бесплатна однозначно однопользовательская версия
3. В свое время мне очень нравилось восстанавливать Paradox таблицы, случайно погибшие потому, что пользователь просто перегружал компьютер нажав на Reset вместо того, чтобы сделать это по правилам.
4. Я лично видал интереснейший глюк Access (до 2000), который откровенно валился при попытке добавить еще одну запись и вс5е из-за того, что размер базы был 30М. Правда с этой базой пытались работать несколько клиентов одновременно.
5. FireBird - хорошо, но уж слишком бедный выбор базовых типов данных по сравнению с Paradox. Особенно меня смущала в свое время отсутствие автоинкрементных полей (хотя проблема и решалась триггерами с генераторами). + FireBird родственник InterBase, которая то стала свободной, то снова закрылась. Это меня тоже настораживает.

evgeg (2002-09-12 20:39:00) [18]
> Вот. Потом IB ИБан#$ся... с IB уже имел опыт столкнуться... не справляется он с БД более 100 метров и 3-5 пользователей, и всё... уже так ресурсы сервера жрёт :(, и тормозит как камаз %

Полная чушь.

MsGuns (2002-09-12 20:30:00) [19]
>GoldMedium (12.09.02 18:34)
>50 метров базы за 600000 записей - многовато (с учетом того, что данные абсолютно не упаковываются).

Не специалист именно в IB, но по опыту скажу, что само по себе кол-во записей НИКОГДА не определяет физ.характеристики БД. Записи бывают разные: от 2 полей в таблице до 200, да и сами поля могут быть от SMALLINT до memo или graph.
Точно знаю одно: использование в качестве связующих ключей или индексов полей длинною более 20 символов (а я видел "шедевры", где ключи были по 255 и даже 1024 символа) ведет к РЕЗКОМУ увеличению размеров и снижению быстродействия БД

Val (2002-09-12 18:43:00) [20]
в одной ветке обо всем? :))
>GoldMedium (12.09.02 18:34)
с учетом того, что данные абсолютно не упаковываются
это означает, что backup/restore не помогает, или что?

Страницы: 1 2 3 4 >

Наверх

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