Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 72   вперед  Ctrl
 Re: Access и FoxPro. Сравнение мощей  [new]
-)
Guest
Sergey Ch

Хотя остатюсь при своем мнении - истинные Гуру форумы как правило не посещают - им просто некогда, так как работа, семья, отдых отнимают много времени...

Кто такие истинные Гуру? Это, что – небожители? Да и вообще, знает хоть один человек ВСЕ возможности продукта (любого) и механизмы его работы на все 100% ? Мой ответ – НЕТ. А если есть стремление к процессу бесконечного познания, то настоящий Гуру – ДОЛЖЕН и ОБЯЗАН посещать форумы (даже в ущерб семье и отдыху)! Не пропагандируйте, пожалуйста – ложные представления о Гуру !
1 мар 06, 12:40    [2403232]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
H5N1
Sergey Ch

На мой взгляд гениальная задумака Алекса при создании данного подфорума как раз и заключалась в том, чтобы нам учиться понимать друг друга.

понимать друг друга могут существа которые находятся на примерно одинаковом уровне развития. Вы же как говорил профессор Преображенский "Вы находитесь на самой низкой ступени развития", "в присутствии 2-х людей с университетским образованием" ...
Чтоб за 10 лет не выяснить элементарных вещей о транзакциях и с упорством барана отрицать очевидное их отсутствие в VFP уже 3-ю неделю ... для такого нужно быть полным дауном.
А вот это уже переход на личности. Непростительно. "Баклажана" я Вам спустил, но теперь - выйдите вон!
1 мар 06, 12:40    [2403235]     Ответить | Цитировать Сообщить модератору
 C++/Linux/FireBird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
1024
Например Interbase 4 версии при любых условиях будет менее
надёжен чем аксес

Вы уверены? Я уверен в обратном. Особенно при приличной нагрузке и плохонькой сети.
1 мар 06, 12:48    [2403296]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Urri
Vlad2005
Повторяю ЕЩЕ раз - да, я верю, что можно
слабать нечто, достаточно устойчиво работающее в сети, и даже,
ууууу... имеющее некий транзакционный механизм, и даже на ВФП,
но стоить это будет на пару порядков порядков больше, чем нечто,
написанное на дельфе/билдере/VB etc... и имеющее в тылу
НОРМАЛЬНУЮ СУБД. А уж про стоимость владения я вообще молчу.
Ну, не на пару порядков.

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

PS: Я не говорю сейчас о маленьких конторках. Там тоже не все однозначно.


Гм... Вот супруга творит некие поделия для медиков. Клиент - Дельфя,
6/7, СУБД - ИБ, версию не скажу, не помню. Основная работа - отчеты.
Сервер - в НЕОБСЛУЖИВАЕМОМ режиме. Т.е. ни сисадминов, ни DBA
эти ребята себе позволить не могут. И ведь работает. И уже долго.
1 мар 06, 12:50    [2403315]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
5631
А я тоже бэкапы умею делать, не только сервер.

На работающей БД?
1 мар 06, 12:54    [2403354]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
5631
To H5N1
Был у нас случай с MS SQL пару лет назад. Запоролся винчестер на сервере. Заметили через 2 дня. Все это время сервер делал бэкапы уже поврежденных данных. Логи остались. Это ты прав. Данные по ним восстановили, но они оказались с пропусками. Данные использовались Access-овской программой и из-за нарушения целостности все перестало работать.
Короче, весь отдел информатики сидел и несколько недель вручную восстанавливал данные.
Ты скажешь про кривые руки. Согласен. Ну так, приходи к нам, администрируй на общественных началах.
Для справки: поврежденную dbf я восстанавливаю за 30 секунд.


DBCC CHECKDB спас бы отцов и основателей отдела.

Давай я тебе пришлю dbf-ину, в кторой помешаны данные (слет программы
при заполнении таблицы). И потом вместе порадуемся восстановлению
буквок и цифирок. А простые коррекции заголовков и простановка
правильного числа строк - дык это половина View'еров умеют.
Сим делом регулярно страдают операторы филиалов, где стоит лисий
склад (скоро переведем ;-))
1 мар 06, 12:57    [2403394]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
I_am222
Guest
Vlad2005

Гм... Вот супруга творит некие поделия для медиков. Клиент - Дельфя,
6/7, СУБД - ИБ, версию не скажу, не помню. Основная работа - отчеты.
Сервер - в НЕОБСЛУЖИВАЕМОМ режиме. Т.е. ни сисадминов, ни DBA
эти ребята себе позволить не могут. И ведь работает. И уже долго.


ну признайте, что это не параметр.. мои программы тоже работают годами не админятся и не падают, равзе это говорит о супернадежности ДБФ-ников?

Скажу одно у кого вагон времени - то пробует то одну СУБД.. то другую.. сравнивает тыкается..., но когда он тогда задачи пишет не понятно :-)

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

Спор ИМХО ерундовый.. аксесс вообще не жилец раз так
1 мар 06, 13:10    [2403513]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Vlad2005
Давай я тебе пришлю dbf-ину, в кторой помешаны данные (слет программы при заполнении таблицы). И потом вместе порадуемся восстановлению
буквок и цифирок. А простые коррекции заголовков и простановка
правильного числа строк - дык это половина View'еров умеют.
Сим делом регулярно страдают операторы филиалов, где стоит лисий
склад (скоро переведем ;-))
Да уж, бывало и в моей практике такое безобразие.
Тут одно из трех помогает:
1. На время превращаемся в следователей и титаническими усилиями восстанавливаем сбой (все же данные портятся, как правило, только в одной таблице за раз, по содержимому других можно целостность базы восстановить).
2. Либо объявляем пользователям, что все, что сделано с прошлого бэкапа, придется переделывать - и возвращаем данные к предыдущему целостному состоянию.
3. Либо заранее пишем двойной программный контроль и временное хранилище для данных, полнота сохранения которых пока не достоверна, и тогда программа сама обнаружит сбой и после его устранения восстановит данные. Но это уже аналог журнала транзакций получается. Вот только многие здесь, кажется, считают, что это - сверхтяжелая задача, и она удорожает стоимость разработки многократно. Нет, знаете ли, ничего страшного. И на фоксе это дело пишется на раз-два.

Я, вообще-то, согласен с тем, что контроль над целостностью БД надо, по возможности, уводить с клиентов. Но и это не означает обязательного применения промышленных клиент-серверных СУБД. Многие критичные процессы и на старых DBF-ах можно унести с клиентов на выделенные сервера приложений. Причем к ним можно достукиваться и через веб-сервисы, и через терминальный доступ, и через написание listener'а, который работает на сервере приложений и слушает команды пользователей, которые передавать можно тучей разных способов, в том числе, через те же dbf-табличные очереди.
1 мар 06, 13:24    [2403601]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
H5N1
Guest
Urri

Я, вообще-то, согласен с тем, что контроль над целостностью БД надо, по возможности, уводить с клиентов. Но и это не означает обязательного применения промышленных клиент-серверных СУБД. Многие критичные процессы и на старых DBF-ах можно унести с клиентов на выделенные сервера приложений. Причем к ним можно достукиваться и через веб-сервисы, и через терминальный доступ, и через написание listener'а, который работает на сервере приложений и слушает команды пользователей, которые передавать можно тучей разных способов, в том числе, через те же dbf-табличные очереди.


ага, соорудить лог, вынести за веб-сервисы ... ах сколько еще открытий чудных.
ну и что вы будете делать с логом (как определить что был сбой) ? что с уровнем изолированости транзакций ? а 2Gb, а оптимизатор, что с ним ? зачем все это делать руками если бесплатные средства где все это есть ?
да, не все sql сервера одинаковы полезны, но даже в mysql есть и лог и read commited, там даже пародия на кластер есть. зачем тратить жизнь на сооружении херни которая заведомо непотянет до самых простых из серверов ??
1 мар 06, 13:37    [2403676]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Urri
Vlad2005
Давай я тебе пришлю dbf-ину, в кторой помешаны данные (слет программы при заполнении таблицы). И потом вместе порадуемся восстановлению
буквок и цифирок. А простые коррекции заголовков и простановка
правильного числа строк - дык это половина View'еров умеют.
Сим делом регулярно страдают операторы филиалов, где стоит лисий
склад (скоро переведем ;-))
Да уж, бывало и в моей практике такое безобразие.
Тут одно из трех помогает:
1. На время превращаемся в следователей и титаническими усилиями восстанавливаем сбой (все же данные портятся, как правило, только в одной таблице за раз, по содержимому других можно целостность базы восстановить).
2. Либо объявляем пользователям, что все, что сделано с прошлого бэкапа, придется переделывать - и возвращаем данные к предыдущему целостному состоянию.
3. Либо заранее пишем двойной программный контроль и временное хранилище для данных, полнота сохранения которых пока не достоверна, и тогда программа сама обнаружит сбой и после его устранения восстановит данные. Но это уже аналог журнала транзакций получается. Вот только многие здесь, кажется, считают, что это - сверхтяжелая задача, и она удорожает стоимость разработки многократно. Нет, знаете ли, ничего страшного. И на фоксе это дело пишется на раз-два.

Я, вообще-то, согласен с тем, что контроль над целостностью БД надо, по возможности, уводить с клиентов. Но и это не означает обязательного применения промышленных клиент-серверных СУБД. Многие критичные процессы и на старых DBF-ах можно унести с клиентов на выделенные сервера приложений. Причем к ним можно достукиваться и через веб-сервисы, и через терминальный доступ, и через написание listener'а, который работает на сервере приложений и слушает команды пользователей, которые передавать можно тучей разных способов, в том числе, через те же dbf-табличные очереди.


Ну, по пунктам.,
\\
1. На время превращаемся в следователей и титаническими усилиями восстанавливаем сбой (все же данные портятся, как правило, только в одной таблице за раз, по содержимому других можно целостность базы восстановить).
\\
Гм. Ну, сие ТОЛЬКО на совести дизайнеров и кодеров. Можно хранить и промежуточные версии документов, что кстати, дисциплинирует манагеров ;-)

\\
2. Либо объявляем пользователям, что все, что сделано с прошлого бэкапа, придется переделывать - и возвращаем данные к предыдущему целостному состоянию.
\\
Дааа.... "Не влезай, убьет" - самое подходящее. Либо - бекапы
через.... 1-2-4 (ненужное сьесть) часов.

\\
3. Либо заранее пишем двойной программный контроль и временное хранилище для данных, полнота сохранения которых пока не достоверна, и тогда программа сама обнаружит сбой и после его устранения восстановит данные. Но это уже аналог журнала транзакций получается. Вот только многие здесь, кажется, считают, что это - сверхтяжелая задача, и она удорожает стоимость разработки многократно. Нет, знаете ли, ничего страшного. И на фоксе это дело пишется на раз-два.
\\
Руками писать журнал транзакций для документов... Эт ж целый банковский
опердень! Не... Но вообще-то - всего лишь несколько запросов, что проверяют
логическую целостность данных, плюс временные хранилища, плюс логи...
ну, и количество бекапов прямо пропорционально спокойствию DBA. От себя
добавлю - ВСЕ, что пишется на раз-два на Лиске, можно реализовать и иными
средствами разработки. Вся задача в правильности потановки. Чем и приходится заниматься львиную долю времени. Так что в правильных руках
и Лис - инстУмент, но, повторюсь, только для мааалых обьектов. Ну не
масштабируется он, хоть тресни.
1 мар 06, 13:52    [2403761]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Sergey Ch
Member

Откуда: Благовещенск
Сообщений: 8894
H5N1
... зачем все это делать руками если бесплатные средства где все это есть ?

Бесплатный только сыр в мышеловке... Стоимость обслуживания может оказаться высока... Особенно мне нравятся подобные фразы про СУБД на основе UNIX

По поводу работы без сбоев. У меня был один рекорд, когда программа проработала 8 лет без обслуживания, я даже успел о ней забыть, причем работала без единого сбоя... Да, не очень хорошая программа - так как клиент заплатил мне всего один раз... и на 8 лет
1 мар 06, 13:55    [2403781]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
Urri
Vlad2005
Давай я тебе пришлю dbf-ину, в кторой помешаны данные (слет программы при заполнении таблицы). И потом вместе порадуемся восстановлению
буквок и цифирок. А простые коррекции заголовков и простановка
правильного числа строк - дык это половина View'еров умеют.
Сим делом регулярно страдают операторы филиалов, где стоит лисий
склад (скоро переведем ;-))
Да уж, бывало и в моей практике такое безобразие.
Тут одно из трех помогает:
1. На время превращаемся в следователей и титаническими усилиями восстанавливаем сбой (все же данные портятся, как правило, только в одной таблице за раз, по содержимому других можно целостность базы восстановить).
2. Либо объявляем пользователям, что все, что сделано с прошлого бэкапа, придется переделывать - и возвращаем данные к предыдущему целостному состоянию.
3. Либо заранее пишем двойной программный контроль и временное хранилище для данных, полнота сохранения которых пока не достоверна, и тогда программа сама обнаружит сбой и после его устранения восстановит данные. Но это уже аналог журнала транзакций получается. Вот только многие здесь, кажется, считают, что это - сверхтяжелая задача, и она удорожает стоимость разработки многократно. Нет, знаете ли, ничего страшного. И на фоксе это дело пишется на раз-два.

Я, вообще-то, согласен с тем, что контроль над целостностью БД надо, по возможности, уводить с клиентов. Но и это не означает обязательного применения промышленных клиент-серверных СУБД. Многие критичные процессы и на старых DBF-ах можно унести с клиентов на выделенные сервера приложений. Причем к ним можно достукиваться и через веб-сервисы, и через терминальный доступ, и через написание listener'а, который работает на сервере приложений и слушает команды пользователей, которые передавать можно тучей разных способов, в том числе, через те же dbf-табличные очереди.


Ну, по пунктам.,
\\
1. На время превращаемся в следователей и титаническими усилиями восстанавливаем сбой (все же данные портятся, как правило, только в одной таблице за раз, по содержимому других можно целостность базы восстановить).
\\
Гм. Ну, сие ТОЛЬКО на совести дизайнеров и кодеров. Можно хранить и промежуточные версии документов, что кстати, дисциплинирует манагеров ;-)

\\
2. Либо объявляем пользователям, что все, что сделано с прошлого бэкапа, придется переделывать - и возвращаем данные к предыдущему целостному состоянию.
\\
Дааа.... "Не влезай, убьет" - самое подходящее. Либо - бекапы
через.... 1-2-4 (ненужное сьесть) часов.

\\
3. Либо заранее пишем двойной программный контроль и временное хранилище для данных, полнота сохранения которых пока не достоверна, и тогда программа сама обнаружит сбой и после его устранения восстановит данные. Но это уже аналог журнала транзакций получается. Вот только многие здесь, кажется, считают, что это - сверхтяжелая задача, и она удорожает стоимость разработки многократно. Нет, знаете ли, ничего страшного. И на фоксе это дело пишется на раз-два.
\\
Руками писать журнал транзакций для документов... Эт ж целый банковский
опердень! Не... Но вообще-то - всего лишь несколько запросов, что проверяют
логическую целостность данных, плюс временные хранилища, плюс логи...
ну, и количество бекапов прямо пропорционально спокойствию DBA. От себя
добавлю - ВСЕ, что пишется на раз-два на Лиске, можно реализовать и иными
средствами разработки. Вся задача в правильности потановки. Чем и приходится заниматься львиную долю времени. Так что в правильных руках
и Лис - инстУмент, но, повторюсь, только для мааалых обьектов. Ну не
масштабируется он, хоть тресни.
1 мар 06, 14:01    [2403813]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Vlad2005
Так что в правильных руках
и Лис - инстУмент, но, повторюсь, только для мааалых обьектов. Ну не
масштабируется он, хоть тресни.
Согласен. У него есть четко очерченные пределы масштабируемости.
1 мар 06, 14:02    [2403816]     Ответить | Цитировать Сообщить модератору
 C++/Linux/FireBird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
Vlad2005
[quot Urri]Дааа.... "Не влезай, убьет" - самое подходящее. Либо - бекапы через.... 1-2-4 (ненужное сьесть) часов.

Ну не умеет VFP делать бэкапы. НЕ УМЕЕТ!
1 мар 06, 14:08    [2403848]     Ответить | Цитировать Сообщить модератору
 Re: C++/Linux/FireBird  [new]
Vlad2005
Member

Откуда: Воронеж
Сообщений: 119
f_w_p
Vlad2005
[quot Urri]Дааа.... "Не влезай, убьет" - самое подходящее. Либо - бекапы через.... 1-2-4 (ненужное сьесть) часов.

Ну не умеет VFP делать бэкапы. НЕ УМЕЕТ!


Хуже того (озираясь и оглядываясь) - он еще и СУБД не является ;-)
1 мар 06, 14:20    [2403917]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

Согласен. У него есть четко очерченные пределы масштабируемости.
--------------

не согласен. Границы масштабируемости (грубо - 10 юзеров на 100 Мб данных)
есть у базы на дбф"ах. Пусть и на современных, в контейнере.

Как у средства разработки морд к серверу подобные границы отсутствуют


Posted via ActualForum NNTP Server 1.3

1 мар 06, 14:21    [2403924]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
1024

Согласен. У него есть четко очерченные пределы масштабируемости.
--------------

не согласен. Границы масштабируемости (грубо - 10 юзеров на 100 Мб данных)
есть у базы на дбф"ах. Пусть и на современных, в контейнере.

Как у средства разработки морд к серверу подобные границы отсутствуют


Ну почему же отсутсвуют, может не в жесткой форме, но они таки есть. Это не самодостаточный язык, без подпорок ввиде ActiveX, которые по большей части платные и без исходников, вот тебе и границы.
1 мар 06, 15:04    [2404260]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
5631
Member

Откуда:
Сообщений: 452
http://www.foxclub.ru/pr_fox/
1 мар 06, 15:08    [2404292]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
I_Am222
Guest
Vlad2005

Так что в правильных руках
и Лис - инстУмент, но, повторюсь, только для мааалых обьектов. Ну не
масштабируется он, хоть тресни.


Согласен не масштабируется, не понятно только одно, почему такой напряг в сторону масштабируемости-то?
неужто кажды программист мечтает, чтобы его магазинчик превратился со временем в интернет-аукцион?
Если вы пишете для магазина, или супермаркета, конечто можно мечтать, что мол когда-то этот магазинчик будет иметь 249 филиалов .. но все же это опять-таки иллюзия...
Да и потом - если Ваша программа супермасштабируема - Вам не заплатят за переделывание?

f_w_p
Ну не умеет VFP делать бэкапы. НЕ УМЕЕТ!

Кстати пробовал нагорячую делать архив БД при помощи Arj32
получилось.. не было матерщины на вопрос "таблицы открыты и используются..."
Сам был удивлен
причина?
1 либо АрЙот так умеет
2 либо мой стиль = селект данных - на контролы формы - поменяли - апдейт обратно, коим-то образом не держит открытые таблицы? (хотя он же держит)
в любом случае допускаю, что если сделать бэкап в момент модификации - целостность нарушится.... но, как всегда не проверив не утверждаю......

В родном городе супермаркет, касс на 20 работает на ФПД 2,6 (судя по морде), и работает - нету сбоев... не верится, что они отошли от ДБФ-ок, хотя кто их знает
Другой супермаркет на 10 касс = 1С, частенько видел, как админ бегает между кассами с просьбой "выключить комп - дать отдохнуть 1С-ке", смешной админ? или смешная 1С кто их разберет.....

Масса того, что бесплатные СКЛ сервера делают можно реаи а голом ВФП
Но самому нравится Оракл, как уже повторял неоднократно, но что делать, если клиенту никак не развернуть ору?
Пробовать интербейс.. ну попробую как-нибудь, если желание возникнет...
если бы дбф-ники падали часто - давно бы уж задумался над переходом на другую СУБД, но пока не падают - то и незачем.
А как клиент в СКЛ серверу ВФП ничем не хуже и не лучше других...
Да вот еще дельфи пробуют угробить непонятно за что.... на одного соперника меньше?
1 мар 06, 15:09    [2404298]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

Это не самодостаточный язык, без подпорок ввиде ActiveX, которые по большей
части платные и без исходников, вот тебе и границы.
---------------------------



вам уже объяснили что поддержка использования COM-объектов в вфп реализована
примерно на том же уровне что и в дельфи или васике.
Назначение вфп - разработка приложений для работы с базами данных (дбф или
какой-нибудь скл сервер). Средств для этого более чем достаточно. Средства
для быстрого решения тригонометрических уровнений в вфп не включены

если вам непонятны объяснения или они вам не нравятся не стоит опять
заводить разговор об одном и том же. Всё уже есть в этом треде.



Posted via ActualForum NNTP Server 1.3

1 мар 06, 15:24    [2404415]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
1024

Это не самодостаточный язык, без подпорок ввиде ActiveX, которые по большей
части платные и без исходников, вот тебе и границы.
---------------------------



вам уже объяснили что поддержка использования COM-объектов в вфп реализована
примерно на том же уровне что и в дельфи или васике.
Назначение вфп - разработка приложений для работы с базами данных (дбф или
какой-нибудь скл сервер). Средств для этого более чем достаточно. Средства
для быстрого решения тригонометрических уровнений в вфп не включены

если вам непонятны объяснения или они вам не нравятся не стоит опять
заводить разговор об одном и том же. Всё уже есть в этом треде.


Вам уже обясняли, что разница между самодостаточным языком и языком основаном на подпорках есть. Для Delphi, COM это как юзание инородного тела, юзать то можно, но зачем оно если все можно сделать средствами языка.

"Есть все" очень близорукое суждение. Стандартных средств никогда не бывает слишком много, жизнь намного богаче, чем любые представления каждого из нас.
1 мар 06, 15:42    [2404588]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267

Вам уже обясняли, что разница между самодостаточным языком и языком
основаном на подпорках есть. Для Delphi, COM это как юзание инородного тела,
юзать то можно, но зачем оно если все можно сделать средствами языка.
------------------------
про недостатки COM-технологии - это ваше личное мнение которое не разделяют
большинство виндовых разработчиков на не-дельфи




"Есть все" очень близорукое суждение. Стандартных средств никогда не бывает
слишком много, жизнь намного богаче, чем любые представления каждого из нас.
-----------------------
средств по работе с данными больше чем в других неспециализированных средах
разработки типа васика или дельфи


Posted via ActualForum NNTP Server 1.3

1 мар 06, 15:51    [2404646]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
5631
Member

Откуда:
Сообщений: 452
Обсудим лучше движок данных в Дельфи. Сравним с FoxPro.
1 мар 06, 15:52    [2404658]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
Alex Ustas
Ну почему же отсутсвуют, может не в жесткой форме, но они таки есть. Это не самодостаточный язык, без подпорок ввиде ActiveX, которые по большей части платные и без исходников, вот тебе и границы.
Ну вот это-то как-раз ерунда. Для того, чтобы сделать приличное приложение, не нужны эти ActiveX совсем! Ну то есть ни одного! Встроенных контролов хватает с избытком. ;-)

21024
согласен с поправкой: как морда к серверу БД - не имеет ограничений.
1 мар 06, 15:57    [2404689]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
I_Am222
Guest
Urri
Alex Ustas
Ну почему же отсутсвуют, может не в жесткой форме, но они таки есть. Это не самодостаточный язык, без подпорок ввиде ActiveX, которые по большей части платные и без исходников, вот тебе и границы.
Ну вот это-то как-раз ерунда. Для того, чтобы сделать приличное приложение, не нужны эти ActiveX совсем! Ну то есть ни одного! Встроенных контролов хватает с избытком. ;-)


точно не ясно зачем разговор об Активиксах.. нету и нету.. никогда не надо было, а у кого желание, чтобы было очень красиво - поясните как это отобразится на работе?
Потому-что они сторонние и делают много хорошего? дык самому писать ИМХО и интересней, и косяки свои, а не чужие...
1 мар 06, 16:09    [2404769]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 28 29 30 31 32 [33] 34 35 36 37 .. 72   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить