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

← →
3JIA9I CyKA © (2002-09-12 16:34) [40]

Борман уже сам признался в нестабильности рагадоха.
И как-то очень легко верится.

← →
Anatoly Podgoretsky © (2002-09-12 16:37) [41]

Engel (12.09.02 16:31)
Local Share=True этого достаточно

← →
Mike Kouzmine (2002-09-12 16:40) [42]

3JIA9I CyKA ©, по всей видимости, в комсомоле никогда не состоял(а), а то бы знал(а), что настоящие комсомольцы, как продолжатели дела коммунистов, ни кому не должны верить, тем более на слово, да еще хоть и известному, но немецко-фашистскому захватчику.

← →
3JIA9I CyKA © (2002-09-12 16:47) [43]

2Mike Kouzmine (12.09.02 16:40)
Нехорошо советовать людям дикий гемор.
Не лучше давать советы по его (гемора) одомашниванию.

← →
Engel (2002-09-12 16:48) [44]

Для Anatoly Podgoretsky:

А вообще можно где-то прочитать про принцип работы dbase в сети? То есть, если строка занята одним пользователем, что в этом случае происходит? Или все обращения на sql-запросы переводить?

И еще - как оформить обновление данных на экране?

Простите за ламерство, но нигде найти не могу.

← →
Mike Kouzmine (2002-09-12 16:53) [45]

Я шучу. Разговор не по делу. Надо в потрепаться. Каждый день одно и тоже. Пошел домой.

← →
GoldMedium (2002-09-12 18:34) [46]

По поводу InterBase. Может кто подскажет, каким образом можно уменьшить размер базы данных на IB.
50 метров базы за 600000 записей - многовато (с учетом того, что данные абсолютно не упаковываются).

← →
Val © (2002-09-12 18:43) [47]

в одной ветке обо всем? :))
>GoldMedium (12.09.02 18:34)
с учетом того, что данные абсолютно не упаковываются
это означает, что backup/restore не помогает, или что?

← →
MsGuns © (2002-09-12 20:30) [48]

>GoldMedium (12.09.02 18:34)
>50 метров базы за 600000 записей - многовато (с учетом того, что данные абсолютно не упаковываются).

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

← →
evgeg © (2002-09-12 20:39) [49]

> Вот. Потом IB ИБан#$ся... с IB уже имел опыт столкнуться... не справляется он с БД более 100 метров и 3-5 пользователей, и всё... уже так ресурсы сервера жрёт :(, и тормозит как камаз %

Полная чушь.

← →
Alex Marmuzevich (2002-09-12 21:16) [50]

Занющим посвящается:
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 21:37) [51]

> отсутствие автоинкрементных полей (хотя проблема и решалась триггерами с генераторами).

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

← →
Виталий Панасенко (2002-09-13 09:02) [52]

>evgeg © (12.09.02 21:37)
> отсутствие автоинкрементных полей (хотя проблема и решалась >триггерами с генераторами).

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

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

← →
Val © (2002-09-13 10:28) [53]

>Виталий Панасенко (13.09.02 09:02)
зато значением генератора можно оперировать.

← →
Polevi © (2002-09-13 10:45) [54]

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

← →
KSergey © (2002-09-13 11:16) [55]

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

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

← →
ShooRoop (2002-09-13 12:00) [56]

MSSQL - идеальная субда, у меня база полтора гига, порядка 40 активно работающих с ней пользователей, живет 2 года без ЕДИНОГО глюка. Стоит своих денег, 100/16.

← →
Alex Marmuzevich (2002-09-14 16:04) [57]

>Погано - это как?!! Может я что-то не так делаю? Может я записи >не так добавляю? О чем речь?!
Сделай форму TTable + TDataSource + TDBGrid.
Открой таблицу с автоинкрементным полем. Добавь строку, свведи данные и сохрани. Без Refresh в виде Close->Open будет очень интересно таблица отображаться.
Если повторить аналогичную процедуру с Paradox таблицей - все отлично

← →
Polevi © (2002-09-14 17:17) [58]

>Alex Marmuzevich (14.09.02 16:04)
вы в суд на майкрософт подадите, они вам денег заплатят за моральный ущерб

> Alex Marmuzevich (14.09.02 16:04)

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

Я вообще не пойму, что трудно TTabe заменить на TQuery с Select * from Table1 ?

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

← →
Mike13 (2002-09-16 00:06) [62]

а никто тут Visual FoxPro не пробовал? работает с данными побыстрее любого Access"a

Так Visual FoxPro или дельфи с Visual FoxPro таблицами

Моё имхо, любую серьёзную базу сразу писать как клиент/сервер; ресурсы нынешних компьютеров это позволяют. Даже если она всегда будет локальной.
По крайней мере, это меньше извращение, чем из локальной лепить сетевую. (Постоянно вижу такое чудо из FoxPro).

← →
Alex Marmuzevich (2002-09-16 11:16) [65]

Почему собственно "TTable вообще не надо использовать для баз Client/Server". Я как-то не читал у Borland ограничений. Да и по-моему, уж лучше TTable, чем RequestLive = true. Кроме того, для ODBC баз что TTable, что TQuery используют единый механизм доступа к данным.

Ну да... попробуйте открыть таблицу записей эдак 10000 в TTable & TQuery, и посмотрите разницу. TTable всегда пытается тянуть индексы, да и автоматическая работа с запросами просто на высоте, иногда вполне может перечитывать всю таблицу после правки одной записи. Так что только TQuery - для сервера, TTable - для файловой базы
Вообще-то действительно, лучше сразу client/server, чтобы потом не переделывать, я сам давно уже отказался от локальных таблиц

На что сменить ГЛЮЧНЫЙ Paradox? Найти похожие ветки