Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 72   вперед  Ctrl
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
Sergey Ch
Alex Ustas
От наших дискуссий, у меня создается такое устойчивое впечатление, что возможность на delphi создать что угодно выше понимания рядового фокспрошника...

Давно так не смеялся...


здоровый смех над собой это нормально.
8 фев 06, 17:57    [2335292]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
luser
Member [заблокирован]

Откуда: Пердыщево
Сообщений: 1246
f_w_p именно на чистом VFP. Вам уже страшно за свое будущее ? :)
8 фев 06, 21:51    [2335946]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
FM32YO aka KID
Member

Откуда: Ukraine
Сообщений: 884
Alex Ustas
От наших дискуссий, у меня создается такое устойчивое впечатление, что возможность на delphi создать что угодно выше понимания рядового фокспрошника


нет не так - "возможность на delphi создать что угодно выше понимания рядового адепта другого языка"
9 фев 06, 09:47    [2336669]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Urri
Member

Откуда: Москва
Сообщений: 2693
f_w_p
А как VFP решает численные задачи?
Медленно.
9 фев 06, 10:03    [2336726]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
luser
f_w_p именно на чистом VFP

Работа с оборудованием на чистом VFP? На 0-м уровне? Ну фокспрошники запиз...сь:-(. И численные методы? И графика?

luser
Вам уже страшно за свое будущее ? :)

Нет, не страшно. Я с 1995 года завязал с Ф/С. И ни разу не пожалел. И почему я, работая на Delphi и С++, используя MSSQL и FireBird должен бояться за свое будующее? Странная логика. Мягко говоря.:-)

P.S.
До 1995 года пользовались Clipper~ом. От FP отказались за его непотребную прожорливость и глючность.
9 фев 06, 10:18    [2336799]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
ASCRUS
Member

Откуда: МО Электросталь
Сообщений: 5994
f_w_p
P.S.
До 1995 года пользовались Clipper~ом. От FP отказались за его непотребную прожорливость и глючность.

А где это там прожорливость и глючность была ? Я 90-95 годах работал на Clipper Summer 87, в 92-95 годах на FP 2.0-2.5 и могу сказать, что по скорости работы FP делал Clipper на ура, замечательно работал под ДОС на Искрах/Истрах/ЕС 1841 и до работы с Windows и ПО под него я и вообще то не знал, что означает слово "глюк" - все работало как часы. Как только Microsoft выкупила фокс и стала "лабать" свою версию под Windows, стало сразу видно, что эти "подделки" во всем уступали удобному и легкому Access 2.0 и уже достаточно мощному по VCL Delphi 2, так что я сделал одно приложение на FP 2.6 Win и честно ушел с фокса, оставив о нем в душе самые добрые воспоминания.
9 фев 06, 10:48    [2336970]     Ответить | Цитировать Сообщить модератору
 C++/Linux/FireBird  [new]
f_w_p
Member

Откуда:
Сообщений: 1603
ASCRUS

А где это там прожорливость и глючность была ?

Если не удавалось запихнуть вверх сетевые драйверы (а на MSDOS 5.0 это частенько случалось), то на 460-480 кб FP отказывался работать напрочь. А переиндексация? Если в момент переиндексации кто-то начал работать с таблицей, то ... Лучше не вспоминать:-). Полное отсутствие типизации приводило к тому, что ошибка могла вывалиться через месяц другой эксплуатации продукта. А размеры выполняемых файлов? Если на 20Мб винт нужно было поставить пяток приложений, то места не хватало. И т.д.
Clipper позволял писать приложения полностью в графике. Не вам говорить какие преимущества это давало в 1992-1993гг.

ASCRUS
Я 90-95 годах работал на Clipper Summer 87, в 92-95 годах на FP 2.0-2.5 и могу сказать, что по скорости работы FP делал Clipper на ура

В 90-95 гг надо было работать на Clipper 5.01. И вообще, стандартные настройки компоновщика отводили 100 кб под ядро и 50 кб под оверлеи. Т.о. программа могла работать в 150 кб свободной памяти, но с соответствующей скоростью. Видимо Вам настроить компоновщик было не досуг?

ASCRUS
честно ушел с фокса, оставив о нем в душе самые добрые воспоминания.

То же самое могу сказать о Clipper.
9 фев 06, 12:35    [2337776]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

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

у студентов которые в вузе учили паскаль остался единственный аргумент, типа
вфп умер давно. Хотя на самом деле всё с точностью до наоборот. И не досужие
рассуждения а свинцовая правда жизни
--------------------------



Borland отказывается от развития Dephi и C++
09 февраля 2006 года, 17:02
Текст: Владимир Парамонов

Компания Borland намерена отказаться от дальнейших работ по
совершенствованию интегрированных сред разработки, сообщает InfoWorld. В
ближайшее время все усилия будут сосредоточены на развитии стратегии
управления жизненным циклом приложений (Application Lifecycle Management,
ALM).

В третьем квартале прошлого года подразделение, занимающееся
интегрированными средами разработки (Integrated Development Environment,
IDE), в частности, JBuilder, Dephi и C++, принесло всего семь процентов от
общего дохода Borland. Это в два раза меньше аналогичного показателя за
третий квартал 2004 года. Предполагается, что после продажи IDE-направление
станет полностью самостоятельным и не будет зависеть от Borland. Правда, ни
предполагаемые покупатели, ни ориентировочная сумма сделки пока не
называются.

Примечательно, что решение о продаже IDE-бизнеса последовало спустя всего
несколько месяцев после назначения нового президента и главного
исполнительного директора Borland. Данную должность в ноябре прошлого года
получил Тод Нильсен, ранее занимавший пост первого вице-президента по
маркетингу и продажам корпорации Oracle. Кроме того, Нильсен руководил
службой маркетинга и отделом проектирования BEA Systems, а также в течение
двенадцати лет работал на различных должностях в корпорации Microsoft.

Между тем, Borland в рамках плана по развитию стратегий управления жизненным
циклом приложений уже приобрела фирму Segue Software, специализирующуюся на
решениях для определения и оценки качества программного обеспечения. Сумма
сделки составила около 100 миллионов долларов США.

http://soft.compulenta.ru/251439/
Тема Ответить


Posted via ActualForum NNTP Server 1.3

10 фев 06, 13:10    [2342715]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
I_Am222
Guest
1024


Borland отказывается от развития Dephi и C++
09 февраля 2006 года, 17:02
Текст: Владимир Парамонов

Компания Borland намерена отказаться от дальнейших работ по



Читал 2 часа назад.. но постеснялся тут постить, дабы не развивать войну

А реально, ИМХО конечно с точки зрения разработки учетных систем разговоры о смерти ВФП или Дельфи или ВБ (этот уже точно не поддерживается) == просто способ заставить людей переходить на другие платформы...
ибо окончание поддержки ведь не значит смерть.. к примеру, все, что мне нужно я могу сделать в ВФП 5,0 (95-й год вроде) точно так же кто-то и на ВБ 4,0 напишет не хуже, а поддержка это что? == введение новых фич, чтобы далее можно было говорить "в дельфи есть то и то.. а в... нету этого... отстойно"
10 фев 06, 15:04    [2343546]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
Да, 1024, ничто не вечно под луной, так и знал что какой-то фокспрошник выложит нечто подобное. Вообще, кажется на rsdn встречал нечто подобное про фокспро: некоторые мертвые живее "живого" фокса. А задел у delphi уже в третьей версии был достаточный, а текущих версий на пяток лет еще хватит. Хотя конечно абыдна, тока народ вздохнул с облегчением в связи с выходом delphi 2006 (10) и такая подстава. Хотя, все может даже и к лучшему, в зависимости от того, кто купит.

p.s. 1024, Вы дискредитировали себя как специалист не могущий аргументировано доказать свою точку хрения, так что оставте ваших студентов и свинцовую правду при себе.

1024

у студентов которые в вузе учили паскаль остался единственный аргумент, типа
вфп умер давно. Хотя на самом деле всё с точностью до наоборот. И не досужие
рассуждения а свинцовая правда жизни
....
10 фев 06, 15:12    [2343616]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

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

p.s. 1024, Вы дискредитировали себя как специалист не могущий
аргументировано доказать свою точку хрения, так что оставте ваших студентов
и свинцовую правду при себе.
---------------------

8)

имеющий ухи да услышит, имеющий глазы да увидит


Posted via ActualForum NNTP Server 1.3

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

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


Borland отказывается от развития Dephi и C++
09 февраля 2006 года, 17:02
Текст: Владимир Парамонов

Компания Borland намерена отказаться от дальнейших работ по



Читал 2 часа назад.. но постеснялся тут постить, дабы не развивать войну

А реально, ИМХО конечно с точки зрения разработки учетных систем разговоры о смерти ВФП или Дельфи или ВБ (этот уже точно не поддерживается) == просто способ заставить людей переходить на другие платформы...
ибо окончание поддержки ведь не значит смерть.. к примеру, все, что мне нужно я могу сделать в ВФП 5,0 (95-й год вроде) точно так же кто-то и на ВБ 4,0 напишет не хуже, а поддержка это что? == введение новых фич, чтобы далее можно было говорить "в дельфи есть то и то.. а в... нету этого... отстойно"


Что не использовали это как аргумент отдельное спасибо, не укаждого достанет выдержки или здравого смысла не использовать эту информацию. Тем более победила не технология, победило мелкомягкое бабло. Тем более, что дальше будет не извество, так как весь девелопмент бизнес выставлен на продажу (а не закрывается), если купить кто-то крупный, то это может и к лучшему для продукта, у Бормана хорошие технологии, но му**ки-менеджеры, не могущие это продать
10 фев 06, 15:19    [2343663]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

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

p.s. 1024, Вы дискредитировали себя как специалист не могущий
аргументировано доказать свою точку хрения, так что оставте ваших студентов
и свинцовую правду при себе.
---------------------

8)

имеющий ухи да услышит, имеющий глазы да увидит


разумеется, достаточно почитать выши посты.
10 фев 06, 15:21    [2343674]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Justanotherguest
Guest
М-дась.... Видать, придется-таки, для "бывших", "частично знавших, но полностью забывших" фокспро товарищей провести очередной ликбез. Исходя из написанного в этой ветке, можно оценить ваши знания VFP в период работы на нем, не более чем на "троячок", господа. Один SQL-блоки частями по 254 символа лепил всю жизнь, вот и Alex Ustas тоже утверждает, что 5 лет работал... Что ж вы, народ, так плохо работаете, если годами вы не можете решить тривиальные проблемы?


Alex Ustas

Пользовался и тем и другим, remote view плох тем, что приходится пересобирать если меняется структура таблиц участвующих в этом remote view, тот еще ад.

Remote View сам по себе вообще малоиспользуем среди пришущих в архитектуре CS в VFP. По причине своих ограничений. Это инструмент для начинающих, либо для сиюминутной выборки "когда рядом стоит начальник". По-сути, это вообще практически визард. Насчет "тот еще ад". Я не понимаю сути проблемы. SQL Pass Through запросы, что, не надо пересобирать если меняется структура таблиц на сервере? Или и в дельфях тоже не надо? Вроде SQL-запрос в TQuery хранится в свойстве SQL имеющий тип TStrings. Он что, святым духом прослеживает изменение структуры таблиц и сам себя перестраивает? Или может проблема в том, что Remote View не открывался визуально после изменения структуры на сервере? Вот поэтому те, кто RV юзает и хранят скрипты для перестройки View (генерится посредством меню view as SQL). Изменили в скрипте структуру, запустили скрипт - получили новый View. Все

sqlconnect/sqlexec - претензий не было б, если можно было сохранять и редактировать основные запросы в компонентах на форме, или хранить ввиде репозитория, как это в delphi tquery, а вспомогательные гнать уже через sqlexec. А так каша. Все вперемешку и код проги и запросы.

И что Вам мешает в этой "вперемешке" упорядочить все как душе угодно? Визуальный класс Custom в VFP для этих целей есть. Создайте от него наследника, обзовите родным сердцу дельфиста словом "TQuery", добавьте символьное свойство SQL, метод ExecSQL, напишите в нем SQLEXEC(This.SQL, <ля-ля-ля>) плюс соотвествующую муть. Кидайте экземпляр класса на форму и заполняйте свойство "SQL". Вызывайте в рантайме TQuery.ExecSQL. Получится объектная обертка над SQLEXEC. Точно такой же оберткой, по-сути, являются соттвествующие классы VCL в Дельфях. В упор не вижу разницы.
P.S. Дельфёвый "репозиторий" = Фоксовская "библиотека классов" (vcx). "Компонент" = "класс". Создаете класс - кидаете в библиотеку, из нее - экземпляр на форму, программно или визуально - как угодно. Дальше можете и саму форму наследовать, если надо, и сам класс TQuery наворачивать в наследниках. Непонятно, почему за 6 лет в FoxPro вы не смогли это сделать

И еще, на сколько помню (но могу ошибиться), remote view открывает свою сессию, sqlconnect/sqlexec свою. Прыкольна.

Прыкольны ваши знания в VFP. Shared Connection поддерживается обоими. По-умолчанию НЕ используется и эту настройку надо выбрать - именно это вам помешало юзать общую сессию?


4) Вы можете при всех официально заявить, что любой ActiveX, разработанный для работы с данными будет работать и с данными Fox? Знаю точно, ComponerntOne ActiveX грид который мы когда-то использовали для работы с даными в VB понятия яне имеет о том что у фокса есть какие-то источники данных.

Если непонятно просьба перечитать
......

Хотя чесна говоря не понял, к чему это вы? Ведь я явно спросил, ActiveX контролол с привязкой к фоксовской базе, возможно ли такое чудо? Раньше точно такого не было.
.....
Итак, резюмируем, фокс только номинально (на бумаге) можно расширить сторонними решениями, реально таких решений практически нет, учитывая, что источник данных фокса никто не понимает, то DB Aware ActiveX вообще нет смысла делать. Ну, вобщем-то, как я и говорил, фокс - решение преимущественно само в себе, без права на альтернативу.

Для начала надо вспомнить, что такое ActiveX и для чего он был создан MS. ActiveX задумывался в первую очередь как средство расширения VB! А что у нас там с данными - Recordset. ADO. Фоксовский курсор - это внутренне представление данных в VFP. Это не рекордсет. И лезет фокс к своим данным не через ADO, а напрямую, без посредников. Поэтому чтобы привязать ActiveX к фоксовскому курсору надо передать курсор через ADO. Всё.... вот и вся проблема. Судя по тому, что Вы настойчиво задаете вопрос "можно или нет?", то делать это в VFP вы тоже не научились. В последних двух версиях для этого используется встроенный базовый класс CursorAdapter, для предыдущих испльзовались подключаемые библиотеки и классы - библиотека vfpcom.dll от самой MS (скачиваемая как AddOn), с методами Cursor2Rs, Rs2Cursor и еще как минимум три штуки аналогичных 3d-party решений с той же функциональностью, наиболее функциональный, если не изменяет память - oledbfox.dll


Вы ошибаетесь, для дельфы написано дясятки а то и сотни подобных решений и кто му же бесплатных, с поддержкой колонок, привязке к базе, редактирванием в дереве (выпадающие списки, выбор даты и так далее) и при этом намного быстрее, VirtualTreeView кажется в сотни раз быстрее, при этом расходует меньше памяти.

Вы действительно считаете, что в стане ActiveX не существует извращенческих TreeView с "выпадающие списки, выбор даты и так далее" ? Вы уверены, что нет ActiveX DB Aware Treeview, цепляющих ADO-рекордсеты? И какие, кстати, проблемы подцепить тривью к фоксовским данным вообще без ADO?


но, есть армия сторонних разработчиков, из известных решений: DOA, ODAC. Что это мне дает? заточенность под конкретное решение, ADO не предоставляет решения, кторые есть в DOA, ODAC. Работать то вы сможет и с ADO, но очевидные и простые рещения с точки зрения вышеназваных решений будете делать, эээ, ну сами понимаете. ;)
Конкуренция, знаете ли, делает свое дело. Иногда это рушечки, а иногда и вполне серьезные рещения, где ADO вообще не рассматривается как альтернаивное решение.

"DOA" - это всего навсего обычная реализация API-интерфейса Ораклового клиента oci.dll для Delphi (подозреваю, что и у ODAC тоже, не видел). Вызовы API фокс поддерживает. Очень надо - пишите аналог DOA для FoxPro. То, что этого до сих пор нет, означает только то, что это никому не было нужно. Если в мире MS тоже есть коммерческие разработки по низкоуровневой работе с оракловым клиентом (не знаю, не искал - не нужно было), и у них есть свой API/COM-интерфейс, то их можно юзать и из под VFP


то что для кого-то уже много лет назад пройденный этап, для вас сегодняшний мейнстрим

Вот например, напрашивается из недавнего... Локальные SQL-выборки на Dataset. Для фокспро - фича, существующая еще со времен досовского FoxPro 2.x (была такая штука - Connection Kit для связи с MS SQL и Sybase из FoxPro DOS, уже тогда выборки с сервера можно быть локальным SQL обрабатывать), для .NET - завтрашний день (LINQ), для Дельфи - послезавтрашний (когда Borland тоже его прикрутит - вроде обещали). К тому же, еще вопрос с какими скоростями это будет работать. Очередные вопли "а нам и не нужна такая фича" я игнорирую. Посмотрим на вас, когда вы его все же получите и что вы тогда петь будете.... Так что, как видим, понятия "пройденный этап" и "много лет назад" работают и тут
10 фев 06, 15:42    [2343852]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
I_Am222
Guest
Alex Ustas
I_Am222
1024


Borland отказывается от развития Dephi и C++
09 февраля 2006 года, 17:02
Текст: Владимир Парамонов

Компания Borland намерена отказаться от дальнейших работ по



Читал 2 часа назад.. но постеснялся тут постить, дабы не развивать войну



Что не использовали это как аргумент отдельное спасибо, не укаждого достанет выдержки или здравого смысла не использовать эту информацию.


дык я пояснил почему для меня "закрытие" технологии не есть аргумент.... закрыли ИМХО ибо мало денег приносин, но не потому, что плохая среда..
ни закрыли и что?
самые "умные" бросятся переписывать все на платформу НЭТ и дай Бог им счастья... потому как не факт, что переписав за год все под "новейшую" технология вдруг не окажетчто ее закрыли
10 фев 06, 16:55    [2344443]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

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

Вывод: технологии приходят и уходят а с головой надо дружить всегда


Posted via ActualForum NNTP Server 1.3

10 фев 06, 18:02    [2344772]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
Мужик, у твоего конька-горбунька всадник есть? Читаешь построчно, или предпочитаешь между строк? Я уже 3 года с этим не работаю.

Justanotherguest

Alex Ustas

Пользовался и тем и другим, remote view плох тем, что приходится пересобирать если меняется структура таблиц участвующих в этом remote view, тот еще ад.

Remote View сам по себе вообще малоиспользуем среди пришущих в архитектуре CS в VFP. По причине своих ограничений. Это инструмент для начинающих, либо для сиюминутной выборки "когда рядом стоит начальник". По-сути, это вообще практически визард. Насчет "тот еще ад". Я не понимаю сути проблемы. SQL Pass Through запросы, что, не надо пересобирать если меняется структура таблиц на сервере? Или и в дельфях тоже не надо? Вроде SQL-запрос в TQuery хранится в свойстве SQL имеющий тип TStrings. Он что, святым духом прослеживает изменение структуры таблиц и сам себя перестраивает? Или может проблема в том, что Remote View не открывался визуально после изменения структуры на сервере? Вот поэтому те, кто RV юзает и хранят скрипты для перестройки View (генерится посредством меню view as SQL). Изменили в скрипте структуру, запустили скрипт - получили новый View. Все


Вообще какой-то странный смысл вложили Вы в свои слова, типа вот "а реальные пацаны пользуются "SQL Pass Through", ну и? я тоже пользовался, и что это снимает проблему с remote view? Все что я хотел сказать, реальзовано - глупо. Вы пытаетесь сравнивать remote view с TQuery, но при этом в упор не видете, что если меняется тип данных/имя поля..., в TQuery предыдущая работа не улетает в трубу, и ничо нигде отдельно хранить не надо, а потом запускать. Т.е. ваше "все" слишком длинное и кривое.

Justanotherguest

sqlconnect/sqlexec - претензий не было б, если можно было сохранять и редактировать основные запросы в компонентах на форме, или хранить ввиде репозитория, как это в delphi tquery, а вспомогательные гнать уже через sqlexec. А так каша. Все вперемешку и код проги и запросы.

И что Вам мешает в этой "вперемешке" упорядочить все как душе угодно? Визуальный класс Custom в VFP для этих целей есть. Создайте от него наследника, обзовите родным сердцу дельфиста словом "TQuery", добавьте символьное свойство SQL, метод ExecSQL, напишите в нем SQLEXEC(This.SQL, <ля-ля-ля>) плюс соотвествующую муть. Кидайте экземпляр класса на форму и заполняйте свойство "SQL". Вызывайте в рантайме TQuery.ExecSQL. Получится объектная обертка над SQLEXEC. Точно такой же оберткой, по-сути, являются соттвествующие классы VCL в Дельфях. В упор не вижу разницы.
P.S. Дельфёвый "репозиторий" = Фоксовская "библиотека классов" (vcx). "Компонент" = "класс". Создаете класс - кидаете в библиотеку, из нее - экземпляр на форму, программно или визуально - как угодно. Дальше можете и саму форму наследовать, если надо, и сам класс TQuery наворачивать в наследниках. Непонятно, почему за 6 лет в FoxPro вы не смогли это сделать


разница? пожалуй вот это:
1) для длинных текстовый данных, чем является запрос, можно использовать стандартный редактор для типа TStrings - редактор строк, или сделать для этого типа и этого проперти свой редактор, с табличками, полями, отладкой, конструированием запросов и тому подобным. А твое текстовое поле какое будет, в одну строку? И кому такое надо?

2) Список полей TQuery можно напрямую связывать db aware контролами.

Так что, то что ты написал, бледное подобие и не стоит реализации.

Justanotherguest

И еще, на сколько помню (но могу ошибиться), remote view открывает свою сессию, sqlconnect/sqlexec свою. Прыкольна.

Прыкольны ваши знания в VFP. Shared Connection поддерживается обоими. По-умолчанию НЕ используется и эту настройку надо выбрать - именно это вам помешало юзать общую сессию?


Мужик, ты наверное дерганный, издергался за фокспро наверное, я ж чесна написал "на сколько помню (но могу ошибиться)", я 3 года к нему не прикасался.

Justanotherguest


4) Вы можете при всех официально заявить, что любой ActiveX, разработанный для работы с данными будет работать и с данными Fox? Знаю точно, ComponerntOne ActiveX грид который мы когда-то использовали для работы с даными в VB понятия яне имеет о том что у фокса есть какие-то источники данных.

Если непонятно просьба перечитать
......

Хотя чесна говоря не понял, к чему это вы? Ведь я явно спросил, ActiveX контролол с привязкой к фоксовской базе, возможно ли такое чудо? Раньше точно такого не было.
.....
Итак, резюмируем, фокс только номинально (на бумаге) можно расширить сторонними решениями, реально таких решений практически нет, учитывая, что источник данных фокса никто не понимает, то DB Aware ActiveX вообще нет смысла делать. Ну, вобщем-то, как я и говорил, фокс - решение преимущественно само в себе, без права на альтернативу.

Для начала надо вспомнить, что такое ActiveX и для чего он был создан MS. ActiveX задумывался в первую очередь как средство расширения VB! А что у нас там с данными - Recordset. ADO. Фоксовский курсор - это внутренне представление данных в VFP. Это не рекордсет. И лезет фокс к своим данным не через ADO, а напрямую, без посредников. Поэтому чтобы привязать ActiveX к фоксовскому курсору надо передать курсор через ADO. Всё.... вот и вся проблема. Судя по тому, что Вы настойчиво задаете вопрос "можно или нет?", то делать это в VFP вы тоже не научились. В последних двух версиях для этого используется встроенный базовый класс CursorAdapter, для предыдущих испльзовались подключаемые библиотеки и классы - библиотека vfpcom.dll от самой MS (скачиваемая как AddOn), с методами Cursor2Rs, Rs2Cursor и еще как минимум три штуки аналогичных 3d-party решений с той же функциональностью, наиболее функциональный, если не изменяет память - oledbfox.dll


Настойчиво потому, что толком из адептов так ответить и не смог никто.
И еще, я закончил серьезно работать с фоксом на 6 версии, тут кто-то ответил, что рекордсеты появились с 8-й. Ну и нахера было писать столько мути?

Justanotherguest

Вы ошибаетесь, для дельфы написано дясятки а то и сотни подобных решений и кто му же бесплатных, с поддержкой колонок, привязке к базе, редактирванием в дереве (выпадающие списки, выбор даты и так далее) и при этом намного быстрее, VirtualTreeView кажется в сотни раз быстрее, при этом расходует меньше памяти.

Вы действительно считаете, что в стане ActiveX не существует извращенческих TreeView с "выпадающие списки, выбор даты и так далее" ? Вы уверены, что нет ActiveX DB Aware Treeview, цепляющих ADO-рекордсеты? И какие, кстати, проблемы подцепить тривью к фоксовским данным вообще без ADO?


ну и как Вы будете цеплять фокспрошные данные, если источник данных рекордсет?

Justanotherguest

но, есть армия сторонних разработчиков, из известных решений: DOA, ODAC. Что это мне дает? заточенность под конкретное решение, ADO не предоставляет решения, кторые есть в DOA, ODAC. Работать то вы сможет и с ADO, но очевидные и простые рещения с точки зрения вышеназваных решений будете делать, эээ, ну сами понимаете. ;)
Конкуренция, знаете ли, делает свое дело. Иногда это рушечки, а иногда и вполне серьезные рещения, где ADO вообще не рассматривается как альтернаивное решение.

"DOA" - это всего навсего обычная реализация API-интерфейса Ораклового клиента oci.dll для Delphi (подозреваю, что и у ODAC тоже, не видел). Вызовы API фокс поддерживает. Очень надо - пишите аналог DOA для FoxPro. То, что этого до сих пор нет, означает только то, что это никому не было нужно. Если в мире MS тоже есть коммерческие разработки по низкоуровневой работе с оракловым клиентом (не знаю, не искал - не нужно было), и у них есть свой API/COM-интерфейс, то их можно юзать и из под VFP


Вопрос лишь в том, что Delphi свой архитектурой способоствует развитию множеству решений, для фокса можно только и ответить: это не нужно потому что не нужно. Хотите дергать API, есть бабки, время? Дергайте на здоровье. Может, премию потом получите, как великомученик.

Justanotherguest

то что для кого-то уже много лет назад пройденный этап, для вас сегодняшний мейнстрим

Вот например, напрашивается из недавнего... Локальные SQL-выборки на Dataset. Для фокспро - фича, существующая еще со времен досовского FoxPro 2.x (была такая штука - Connection Kit для связи с MS SQL и Sybase из FoxPro DOS, уже тогда выборки с сервера можно быть локальным SQL обрабатывать), для .NET - завтрашний день (LINQ), для Дельфи - послезавтрашний (когда Borland тоже его прикрутит - вроде обещали). К тому же, еще вопрос с какими скоростями это будет работать. Очередные вопли "а нам и не нужна такая фича" я игнорирую. Посмотрим на вас, когда вы его все же получите и что вы тогда петь будете.... Так что, как видим, понятия "пройденный этап" и "много лет назад" работают и тут


да хто ж спорит, есть и свои положительные моменты, но мне они ни к чему, все положительное фокса от базы, в моем случае, перекрываются MSDE, firebird etc.
10 фев 06, 18:08    [2344805]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Совсем про бедный Access забыли . Ну ды и понятно. Пишет на нем народ. Прекрасно понимает его недостаточность для ряда задач. Не кричит, что Access может все. Не вылезает из полуобвалившихся окопов с развернутыми знаменами.
============
Вот когда я хоть один раз увижу нормально написаный на VFP интерфейс к базе, то может быть я и полюблю VFP. Скриншотики хоть киньте, пожалуйста. Если надо - я дельфийские положу.
И того убожества, которое у меня на работе на VFP крутиться. Впрочем, и на дельфях можно гавно написать.
===========
Возможно - есть они жемчужины программирования на VFP, но мне не попадались.
===========
А почему на всех прогах которые я видел на VFP, заблокирована кнопка окна "закрыть приложение - крестик" и выход по Alt-F4?
===========
Тему о файл-серверной технологии мне и обсуждать уже лень.
10 фев 06, 19:17    [2345083]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
luser
Member [заблокирован]

Откуда: Пердыщево
Сообщений: 1246
Alex Ustas:
1) Data Set, что , великое творение мысли программистов Microsoft ? Интересно где ты видишь его приимущества над курсором VFP ?
2) Набор данных в виде Data Set с сервера можно вернуть и в 6 фоксе через ADO. ТЫ же наверное знаешь что оно интегрировано в систему ( я имею ввиду не ADONET) и что будет для тебя самое удивительное фокспрошными умельцами даже написаны функции в виде библ DLL\FLL по преобразованию DS->CURSOR и обратно.
Cat2:
автор
Вот когда я хоть один раз увижу нормально написаный на VFP интерфейс к базе, то может быть я и полюблю VFP. Скриншотики хоть киньте, пожалуйста. Если надо - я дельфийские положу.
И того убожества, которое у меня на работе на VFP крутиться. Впрочем, и на дельфях можно гавно написать.

Когда ты увидишь нормальное приложение на VFP тебе станет больно за бесцельно прожитые годы. Так , что считай что тебе везет, что попадаются такие приложения, которые поднимают твою внетреннюю самооценку :)
11 фев 06, 00:12    [2345801]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
luser . Спасибо на добром слове
11 фев 06, 00:21    [2345815]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Justanotherguest
Guest
Я уже 3 года с этим не работаю.
.....
я 3 года к нему не прикасался

Все больше убеждаюсь, что фокспре сильно повезло

Вообще какой-то странный смысл вложили Вы в свои слова, типа вот "а реальные пацаны пользуются "SQL Pass Through", ну и? я тоже пользовался, и что это снимает проблему с remote view? Все что я хотел сказать, реальзовано - глупо. Вы пытаетесь сравнивать remote view с TQuery, но при этом в упор не видете, что если меняется тип данных/имя поля..., в TQuery предыдущая работа не улетает в трубу, и ничо нигде отдельно хранить не надо, а потом запускать. Т.е. ваше "все" слишком длинное и кривое.

Софистика на пустом месте для тех, кто знает о чем речь

разница? пожалуй вот это:
1) для длинных текстовый данных, чем является запрос, можно использовать стандартный редактор для типа TStrings - редактор строк, или сделать для этого типа и этого проперти свой редактор, с табличками, полями, отладкой, конструированием запросов и тому подобным. А твое текстовое поле какое будет, в одну строку? И кому такое надо?

см. методы ReadProperty/WriteProperty - хоть редактор делай, хоть что. Очередная по счету дыра в знаниях VFP

2) Список полей TQuery можно напрямую связывать db aware контролами.

Реализуемо в VFP в 2 счета

Так что, то что ты написал, бледное подобие и не стоит реализации.

Твои личные проблемы как реализатора - ничем не могу помочь



И еще, на сколько помню (но могу ошибиться), remote view открывает свою сессию, sqlconnect/sqlexec свою. Прыкольна.


Прыкольны ваши знания в VFP. Shared Connection поддерживается обоими. По-умолчанию НЕ используется и эту настройку надо выбрать - именно это вам помешало юзать общую сессию?



Мужик, ты наверное дерганный, издергался за фокспро наверное, я ж чесна написал "на сколько помню (но могу ошибиться)"

1. "Дерганый" пишется с одной "н"
2. Если ты написал "на сколько помню (но могу ошибиться)", то не надо было умничать и язвить своим перлом "прЫколнА". Не знаешь - лучше промолчи, и уж по-меньшей мере не умничай

И еще, я закончил серьезно работать с фоксом на 6 версии, тут кто-то ответил, что рекордсеты появились с 8-й. Ну и нахера было писать столько мути?

Повторяю для не умеющих читать:
для предыдущих испльзовались подключаемые библиотеки и классы - библиотека vfpcom.dll от самой MS (скачиваемая как AddOn), с методами Cursor2Rs, Rs2Cursor и еще как минимум три штуки аналогичных 3d-party решений с той же функциональностью, наиболее функциональный, если не изменяет память - oledbfox.dll

Рекордсет в 8-й версии не "появился". Стал доступен встроенный конвертор RS->Cursor, Cursor->Rs. В предыдущих версиях задача конвертирования рекордсета в курсор и обратно решалась посредством подключения внешних библиотек. Кроме того, ADO и до VFP8 всю жизнь было доступно в VFP как COM-сервер (oRs = CREATEOBJECT("ADO.Recordset") - снова твоя дыра в знаниях VFP). Работа с ADO ничем в VFP не отличается от VB. Хочется - работай, только нах это никому не нужно - теряются все приемущества БД-движка FoxPro, т.к. возможности ADO по сравнению с курсором - жалкое зрелище

ну и как Вы будете цеплять фокспрошные данные, если источник данных рекордсет?

Мне отквотить параграф с предыдущего поста? Читай внимательнее


Вопрос лишь в том, что Delphi свой архитектурой способоствует развитию множеству решений, для фокса можно только и ответить: это не нужно потому что не нужно. Хотите дергать API, есть бабки, время? Дергайте на здоровье. Может, премию потом получите, как великомученик.

Перл про великомученика пропускаем как дешевую попсовую гиперболу. Насчет остального - а зачем что-то нужно, если на это нет спроса? Если говорить про Oracle, то по данным, недавно опубликованным MS, непосредственно с Oracle работают лишь 14% фокспрошников. А скольким из них нужны дополнительные навороты, предлагаемые OCI? И к тому же, ты зря думаешь, что я ревниво отношусь к Дельфям. Отнюдь. VCL - замечательная вещь, не зря MS в .NET именно по этой стезе пошло, но БД-подсистема дельфей - г... Это мое мнение как человека, который видел где это реализовано лучше, и пользовался этим. DOA - замечательная вещь, но дельфевая дубовость в локальной обработке данных нивелирует все плюсы компоненты лично для меня. Для моей работы, в той ее части, что касается Оракла, больше чем Оракловая ODBC-дровина и VFP ничего не нужно. Я не знаю о каких таких задачах ты говорил, утверждая, что вам не может их решить OLE DB Provider и ADO - меня это не волнует. Меня волнует моя работа. Будет не хватать возможностей VFP - уйду на ту систему, где такие возможности будут. Будет ли это Дельфя32, .NET, Дельфя.NET или PowebBuilder - мне, по-большому счету, все равно
11 фев 06, 01:22    [2345914]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Cat2
Member

Откуда: Petroskoi, Karjala
Сообщений: 145754
Скромно так.
Все жe может быть разъяснит мне, почему в тех прогах, которые я видел, была блокирована оконная кнопка "Закрыть". Это неумение фокса работать с событиями на уровне ОС или тупизм разработчиков? По
нятно, что не всегда можно просто закрыть прогу не выполнив каких-то действий. Но почему в фоксе это реализуется только ТАК?

Это не мелочь. Юзеры сейчас не те, что были 10 лет тому назад. Они привыкли к стандартным поведениям прог. И они теряются когда попадают в нестандартные ситуаци.
Когда для выхода надо не шелкнуть по кресту, а выбрать в меню пункт "выход" :)
11 фев 06, 01:51    [2345949]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Мшсещырф
Guest
Cat2
Все жe может быть разъяснит мне, почему в тех прогах, которые я видел, была блокирована оконная кнопка "Закрыть". Это неумение фокса работать с событиями на уровне ОС или тупизм разработчиков?


про фокс не скажу, потому что его не знаю.

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

в переводе на человеческий (применительно к акцессу)
"неумение работать с событиями ОС" - будет означать отсутствие снабженного
функциями обработки событий типа "старт-закрытие приложения" глобального объекта уровня приложения.
Правда, применительно конкретно к кресту это мало что оправдывает.

"тупизм разработчиков" - здесь прямее и буквальнее - отсутствие у "разработчиков" знаний по управлению такими ситуациями.
Хоть природа этого "тупизма" - самостоятельный и, вероятно, малоинтересный разговор, само по себе слово вполне подходящее.

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


Вот в Excel тоже пишут приложения. местами даже сложные весьма и интерфейсно мало о приложении-контейнере напоминающие.
Хоть и редко, а встречаются.
Но вот ни одного с "заблокированной оконной кнопкой закрыть" увидеть не довелось.
Следует ли из этого, что люди, начинающие что-то писать под Ексель в среднем "острее" тех, кто пишет на акцессе (или фокспро)?

:)


(
кстати, очень даже может быть, что так и есть
:))
Правда и в том, что, вероятно, в акцессе - заблокированный крест изначально непростительнее, чем в фокспро.
Поскольку в конечном счете свидетельствует не более чем "тупизм".
:)

)


Итак, пусть останется единственно правильный (по крайней мере на "современный момент") ответ - "тупизм разработчиков".

Что он должен прибавить или убавить в плане "сравнения мощей".
или еще в каком-нибудь плане?
11 фев 06, 03:43    [2346054]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
1024
Member

Откуда: Нижний Новгород
Сообщений: 14267
автор
Скромно так.
Все жe может быть разъяснит мне, почему в тех прогах, которые я видел, была блокирована оконная кнопка "Закрыть". Это неумение фокса работать с событиями на уровне ОС или тупизм разработчиков? По
нятно, что не всегда можно просто закрыть прогу не выполнив каких-то действий. Но почему в фоксе это реализуется только ТАК?

Это не мелочь. Юзеры сейчас не те, что были 10 лет тому назад. Они привыкли к стандартным поведениям прог. И они теряются когда попадают в нестандартные ситуаци.
Когда для выхода надо не шелкнуть по кресту, а выбрать в меню пункт "выход" :)


если вы смотрели поделки студентов - посмотрите хоть на моё междумордие, нормально там всё с крестами на кнопках. Если интересует именно картинки интерфейса то можно поискать по этому же форуму, большой топик со скриншотами (дельфисты так и не смогли предоставить ничего приемлимого 8)

об интерфейсе вообще: щас работаю в проекте где интерфейс под сан на библиотеках Motif. Т.е. не просо лажа а полное г. Написан на цпп. И ничё, никто не просит переделать т.к. в данном конкретном проекте это не на первом месте.
11 фев 06, 15:21    [2346608]     Ответить | Цитировать Сообщить модератору
 Re: Access и FoxPro. Сравнение мощей  [new]
Alex Ustas
Member

Откуда:
Сообщений: 281
luser
Alex Ustas:
1) Data Set, что , великое творение мысли программистов Microsoft ? Интересно где ты видишь его приимущества над курсором VFP ?
2) Набор данных в виде Data Set с сервера можно вернуть и в 6 фоксе через ADO. ТЫ же наверное знаешь что оно интегрировано в систему ( я имею ввиду не ADONET) и что будет для тебя самое удивительное фокспрошными умельцами даже написаны функции в виде библ DLL\FLL по преобразованию DS->CURSOR и обратно.


Для начала, можно и на Вы, ну и кажется, Вы совсем потеряли нитку треда, и задаете вопросы не впопад. Лана, мой ответ, преимущество в том, что dataset объект и с ним можно работать как с объектом. Разумеется, у всего есть свои недостатки.
12 фев 06, 03:43    [2347246]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 11 12 13 14 15 [16] 17 18 19 20 .. 72   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить