» Вопросы по компонентам для Delphi, C++ Builder 2

xy

Цитата:

проблема в том, что всё бы ничего, да и многие вообще об этом не задумываются, но тут мне как-то показали что вот в dbf как всё классно, и я призадумался - нельзя же прогрессивным SQL-архитектурам уступать на этом поприще

Это тебе случайно dbf через BDE показали.
Тута тебе прийтедся другим путем идти вопрос достаточно обширный и уже немало статей на энту тему есть.
Имхо есть два пути первый не выбирать огромные набором данных которые нужно обновлять (сразу отступлюсь тоже изьезженая тема кто сможет осязнуть сразу 10000 динамически обновляемых записей) и обновление через равные промежутки времени (а некотрые особо критичные завяляю что мол если пользователю так хочется видеть все быстро то пусть и сам обновляет даеш каждому кнопку рефреш), либо свой клиент сервер который уведомляет о изменении всех клиентов и соотвественно что тоже не есть гуд. Ну а вибырать или иобретать конечно тебе но легкого и простого способа нет.

xy, для Firebird используй FIBPlus - лучшее (но немного платное) на мой взгляд решение. Для отслеживания изменений в Interbase/Firebird можно использовать механизм событий (events). Чтобы не делать полный fetch, можно у таблицы сделать поле типа LastUpdateNumber или LastUpdateTime и обновлять его каждый раз при создании/изменении записи, а при фетче выбирать только записи, у которых LastUpdate... больше, чем был максимальный при предыдущем фетче, минус какое-то значение (чтобы не пропустить записи, обновленные во время предыдущего фетча). Но гуру рекомендуют не заморачиваться с автообновлениями, а сделать кнопку "Обновить", которую юзер сможет педалировать вручную. Впрочем, никто не заставляет следовать советам гуру.

Цитата:

спасибо, но на транзакциях я уже собаку съел, да не одну

Это, мягко говоря, не правда, по крайней мере, применительно к Firebird. Это же надо придумать утверждать, что

Цитата:

в SQL-архитектуре я натолкнулся на проблемки при одновременном внесении данных

Вообще-то, как раз СУБД типа Firebird позволяют решать проблемы многопользовательской работы, которые существовали в dbf/BDE и тому подобном.
Если есть желание научиться качественно писать многопользовательские клиент-серверные приложения под Firebird, для начала welcome to www.ibase.ru и http://www.sql.ru/forum/actualtopics.aspx?bid=2. Понадобится достаточно много времени, чтобы все это освоить и не задавать больше таких вопросов. Писать логику внутри сервера будет трудно (а именно так придется поступать, если не создавать третье звено, что еще труднее), но оно того стоит. Доходит до смешного. Мне нравилось делать к программам на BDE заставки, а теперь я не могу их делать, так как на правильно реализованных Firebird-приложениях даже при многопользовательской работе обработка происходит мгновенно (за исключением специфических задач).

RedPromo
Цитата:

Это тебе случайно dbf через BDE показали.

нет, не через БДЕ
даже не уверен что в БДЕ сие сохранилось, БДЕ ведь тоже через SQL работу организовывает - впрочем про БДЕ не интересно

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

ЗЫ. кстати не совсем понятно как может происходить мгновенно скажем редактирование (точнее загрузка) справочника большого, когда пользователь вполне законно хочет моментально передвигаться по всей таблице и совершенно не хочет ждать фетч когда он нажимает Ctrl-End ;)
если сможете чем помочь - буду очень признателен ;)

Цитата:

технологию подобную этому я и собирался применять, только надеялся что есть решения проще

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

Цитата:

ЗЫ. кстати не совсем понятно как может происходить мгновенно скажем редактирование (точнее загрузка) справочника большого, когда пользователь вполне законно хочет моментально передвигаться по всей таблице и совершенно не хочет ждать фетч когда он нажимает Ctrl-End

Если где-то происходит загрузка большого справочника, значит при проектировании запросов к базе (а может и самой базы) допущены серьезные ошибки. Как справедливо заметил выше RedPromo,

Цитата:

кто сможет осязнуть сразу 10000 динамически обновляемых записей

?
Уверяю, что у пользователя не только не будет желания

Цитата:

моментально передвигаться по всей таблице

, такая мелькающая в процессе обновления таблица на 10000 записей будет сниться ему в страшных снах.
В правильно спроектированной базе, при правильно созданных индексах, правильных планах запросов и так далее, фетч на несколько тысяч записей (а больше и не надо) будет происходить достаточно быстро (при не совсем убитой сетке). Конечно, необходимо грамотно настроить FIBPlus или иные используемые на клиенте компоненты. А как избежать тормозов при отображении, зависит от используемых средств визуализации. Например, в ExpressGrid можно поиграть с GridMode.
Вообще-то это все мало касается компонентов Delphi (компоненты тут - дело десятое). Тут надо принципы построения клиент-серверных приложений рассматривать, а в данном случае применительно к СУБД Firebird. Поэтому, настоятельно рекомендую переместиться в http://www.sql.ru/forum/actualtopics.aspx?bid=2. Там помогут, если правильно задавать вопросы.

Цитата:

проблема в том, что всё бы ничего, да и многие вообще об этом не задумываются, но тут мне как-то показали что вот в dbf как всё классно, и я призадумался - нельзя же прогрессивным SQL-архитектурам уступать на этом поприще

бред полный... надо чтобы вам еще показали как в SQL намного класснее


Цитата:

ЗЫ. кстати не совсем понятно как может происходить мгновенно скажем редактирование (точнее загрузка) справочника большого, когда пользователь вполне законно хочет моментально передвигаться по всей таблице и совершенно не хочет ждать фетч когда он нажимает Ctrl-End

А вот этого не понимаю, никогда не поверю, что рядовому пользователю нужно видеть на экране больше скажем 100 записей. Он не может одновременно редактировать даже две. Поэтому даже справочник надо показывать порциями.

Пользователю вполне законно можно обяснить что он не правильно хочет . Для чего ему нужно передвигаться ??? Если для поиска чего либо, Значит вы должны сделать ему удобный поиск и т.д.

Вообще на эту тему много писали, если есть желание можно в Интернет многое найти.

Ну а напоследок, архитектура приложений с локальными БД, отличается от архитектуры приложений с SQL серверами.
Поэтому можно сказать: вы просто не умеете их готовить

Sexton
xy
согласен, тема не для данного топика, а для sql.ru

jonikDk
преклоняюсь перед гением вашей несостоятельности :):)

Sexton
ладно, попробую выяснить на другом форуме, жалко что наши местные только трепаться умеют :(

xy, зря ты так. jonikDk абсолютно прав. Что поделаешь, я бы тоже хотел, чтобы мир был проще.
Если хочешь сделать что-то похожее на программу, сорвать со спонсора бабок и сбежать в Турцию, то можно сильно не замарачиваться, а если хочется стать специалистом по разработке клиент-серверных приложений, то не стоит считать это халявой и рассчитывать сделать крутую сетевую прогу "по-быстрому" - не получится.
На sql.ru по ссылке, что я дал, сидят одни из лучши спецов по Firebird, включая самих разработчиков Firebird. У них можно многому поучиться. Вначале, конечно, они будут смеяться и издеваться над задаваемыми вопросами, но если не обращать на это внимания, то через какое-то время тоже сможешь забыть про заставки и песочные часы в своих прогах. Удачи в этом.

xy
Вот несколько вопросов:
1. Зачем нужны нормальные формы?
2. Зачем нужно ACID?
3. Зачем нужен SQL сервер?
Чтобы на них ответить, нужно почитать "немножко" умных книжек.
И потому "учиться, учиться и учиться". Поскольку ты сейчас этих вопросов даже не поймешь. А это - азы.

Figaro2000

Цитата:

согласен, тема не для данного топика, а для sql.ru

Тут вообще нет темы. xy совершенно не понимает принципов работы различных СУБД. Он вообще об работе с данными без понятия. Потому на любом форуме его отправят учиться, т.е. читать доки.

Цитата:

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

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

SergeBS
возможно просто вы пытаетесь сделать себе жизнь проще, а я сделать пользователям удобнее - дело ваше, с вами разговор окончен
Основы SQL, и т.п. я прекрасно знаю, увы вы как-то совершенно не попытались понять суть проблемы - ведь не зря я запостил вопрос сюда, а не в ветки по БД и SQL, т.к. меня не особо интересуют неизвестные мне возможности БД, а интересовала возможно существование готовых решений для вполне конкретной задачи;)

Лечить меня что я не знаю (или даже не понимаю) что мне нужно - это очень правильная логика людей, неспособных к ответу (помоему в СОГЛАШЕНИЕ ПО ИСПОЛЬЗОВАНИЮ ФОРУМА рекомендуется в таких случаях промолчать - дело не моё, я не здесь модератор :)

Sexton
не совсем так, людям совершенно необходимо видеть полный справочник, некоторая аргументация есть здесь: http://www.interbase-world.com/ru/articles/2350.php
у меня же на первом месте стоит привычка пользователей, т.е. задача не ломать их стереотипы, но и не проиграть в скорости
методика приемлимая (хоть и устаревшая) есть здесь: http://ibase.ru/devinfo/clientrefresh.htm

это и много другое давно мною читано, но вот когда захотелось использовать, на меня набросились, что я только вчера услышал слово SQL :(
это и огорчает

Добрый день! Встечалась мне такая штука как визад установки компонент без пакета (вернее в пользовательский пакет) Назывался что-то ComponentInstall или как то похоже. Никто не знает где живёт этот зверь? Гуглил-гуглил и не нагуглил.. Может кто помнит?

Цитата:

это и много другое давно мною читано, но вот когда захотелось использовать, на меня набросились, что я только вчера услышал слово SQL это и огорчает

Обсуждение просто не совсем для этого топика, как уже было сказано. Если обсуждать компоненты, то для доступа к Firebird наиболее быстрые и гибкие возможности предоставляет FIBPlus при правильной настройке. Несколько тысяч записей влетают мгновенно. Больше просто я не смог придумать, как использовать.
В приведенной статье (http://www.interbase-world.com/ru/articles/2350.php) какие-то непонятные аргументы приводятся про необходимость анализа. Так зачем выводить промежуточные результаты этого анализа, если пользователю нужен конечный. Ну не может физически человек охватить тысячи записей сразу, не может. А если аффтар статьи не может придумать гибких способов анализа, а хочет, чтобы бедный ползатель ползал вручную по его огромной таблице и сам искал, что ему надо, то пусть аффтар лучше детективы пишет, а не программы. Есть множество компонент-надстроек, позволяющих конечному пользователю, не зная SQL, формировать запросы к базе для получения необходимой информации: это всевозможные фильтры и SQL-билдеры. Например, Korzh Query Builder. Автоматизировать надо работу пользователя, а не подсовывать ему многокилометровые распечатки "для анализа".
Кхм, так вот о компонентах. На тысячах записей тормозил ExpressGrid при обработке lookup-полей (не датасетовских, конечно - про них лучше забыть, а встроенных в грид), но при использовании для загрузки GridMode, а затем его отключении все стало летать. Можно использовать GridView (www.bergsoftware.net) - очень шустро работает с большими наборами данных.
http://ibase.ru/devinfo/clientrefresh.htm я конечно читал в свое время и даже хотел использовать, но необходимость правки исходников компонент, избыточное логирование инсертов и апдейтов... Вообщем, я пошел своим путем.

Sexton
Цитата:

FIBPlus при правильной настройке. Несколько тысяч записей влетают мгновенно.

спорное утверждение - вас избаловали 100мбитные сети :)
я же работаю с ситуацией, когда 1мб данных (5тыс больших записей) передается по сети секунд 5-10, согласитесь на мгновенность не тянет ;)


Цитата:

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

в ФИБах уже давно бага на DeleteSQL нет ;)
а вот во время заставочки подгрузить 5-10секунд большой набор, а потом походу его обновлять - это помоему неплохая идея

to waik

боюсь обидеть, но может быть то что ты ищешь находиться в самой Delphi...

Меню Компонент - Install Component. Выбираешь pas файл и по умолчанию он вставит в пользовательский пакет dclusr.dpk

jonikDk
Не! не обидел... Это вообще не для меня. А насчёт меню... попробуй это сделать в BDS ( действительно надо было указать в вопросе - сорри) Руками открыть пакет и добавить - вопросов нет, но нужно именно через тот визард. Люди разные бывают и все называют себя программерами...

xy, тогда работа а-ля ClientDataSet или сервер приложений или сетку наладить (разработка под такую сетку выйдет дороже) или вообще другую СУБД (технологию) выбрать...

xy

Цитата:

Основы SQL, и т.п. я прекрасно знаю,

Только не надо ля-ля.
1.

Цитата:

Здравствуйте, подскажите пожалуйста где можно развернуто прочитать про работу нескольких пользователей с одним набором данный
есть ли у dataset стандартный механизм обновления (без полного fetch) или как это можно сделать
данная функциональность прекрасно реализована при работе с dbf(клиенты там работают фактически с одним физическим файлом и сразу видят чего менялось), а вот в SQL-архитектуре я натолкнулся на проблемки при одновременном внесении данных

Т.е. "Многопользовательская работа с dbf" - этого достаточно, чтобы сделать вывод о "прекрасном знании" основ многопользовательских приложений. Сравнивается то, чего нет (на dbf) с тем, что проблем не имеет.

2.

Цитата:

БДЕ ведь тоже через SQL работу организовывает

Еще одно проявление "знания". BDE работает через IDAPI, который обращается к соответствующему драйверу. Для локальных форматов (dBase, Paradox, FoxPro) драйвер работает с данными/индексами сам. Для SQL Link - происходит преобразование в вызовы API функций сервера. Именно поэтому BDE работает с dbf быстрее, чем ADO, которые действительно все делают через SQL-запросы.

3.

Цитата:

т.к. меня не особо интересуют неизвестные мне возможности БД, а интересовала возможно существование готовых решений для вполне конкретной задачи;)

Которые уже есть, причем давно, и тема посылки с сервера обновлений на клиента по факту изменения данных другим клиентом - поднималась много раз. В том числе и для ЖарПтицы. В соответствующих местах. Поскольку к Делфи это никакого отношения не имеет - никакими хитромудрыми компонентами это решено быть не может по ОЧЕВИДНОЙ причине: об изменении данных клиент может узнать только от сервера, либо сам запросив (никаких хитростей не надо), либо с помощью реализованных на сервере хитростей без запроса получив обновление по инициативе сервера.
Резюме: проблема в том, что кое-кто (не буду показывать пальцем) по причине "глубоких знаний" пытается на самолете до Луны долететь.
А вот это:

Цитата:

возможно просто вы пытаетесь сделать себе жизнь проще, а я сделать пользователям удобнее

классическая отмазка. Сделать как надо не получается, поэтому делается абы как. А ведь нормальные формы - это очень просто. И курсор на клиенте на Нобелевку тоже не потянет.

OXDBA

Цитата:

Только на сиквелру не ходи, а то там Карабас Барабас

Да брось. Что-то я там такого не заметил. Ткни пальцем типа url (если не лень), в пример.


Цитата:

тогда надо смотреть в сторону многозвенки с локальной буферизацией данных(один раз качаем все, потом гоним только изменения)

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

Sexton
ну проблема не так велика чтоб всё ломать :)

OXDBA
Цитата:

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

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

Добавлено:

Цитата:

Которые уже есть, причем давно, и тема посылки с сервера обновлений на клиента по факту изменения данных другим клиентом - поднималась много раз. В том числе и для ЖарПтицы. В соответствующих местах. Поскольку к Делфи это никакого отношения не имеет - никакими хитромудрыми компонентами это решено быть не может по ОЧЕВИДНОЙ причине: об изменении данных клиент может узнать только от сервера, либо сам запросив (никаких хитростей не надо), либо с помощью реализованных на сервере хитростей без запроса получив обновление по инициативе сервера.

это всё понятно, поэтому я и сразу попросил ссылки, где почитать
и совершенно не просил убеждать меня что я чего-то не знаю ;)

Цитата:

Да брось. Что-то я там такого не заметил. Ткни пальцем типа url (если не лень), в пример.

Ну как же.

Уважаемые, давайте будем внимательнее друг к другу...

xy
Внимательно прочитал обсуждение твоего вопроса. Складывается ощущение, что ты просто нечетко его сформулировал.
Попробую описать свой способ решения подобных задач. При условии, что я правильно тебя понял

Есть замечательная штука - Firebird embedded. Включаем его в клиентский дистрибутив вместе с актуальной базой. В справочники, например, добавляем поля Created и Modified (timestamp). И не забываем подгружать с сервера обновления. Автоматом или по нажатию кнопки - не принципиально.

В итоге может получиться едва ли не полноценная репликация, конечно. Но пользователь не зависит от доступности и скорости сети. Если не ошибаюсь, подобный подход называется "briefcase model".

Arvur, зачем такие сложности? А обратно ведь данные тоже гнать нужно и разруливать конфликты между "посылками" от разных клиентов. Это сервер приложений с репликатором получается. Только при чем тут Firebird embedded...
Чем не нравится ClientDataSet, тем более, что Фибы умеют работать в таком режиме?

SergeBS
Теперь нашел? Просто я намекал на специфику формулирования ответов на sql.ru.
Теперь по поводу многозвенки. Я же не зря упомянул локальную буферизацию. Например есть ряд приложений, работающих в локалке на сотке с базой ~20ГБ, здесь классический клиент-сервер о котором тут столько шумят. Все было бы хорошо, но еще присутствует ряд клиентов сидящих на узком, кривом канале и за время выполнения запроса к БД "напрямую"(1-2 сек) соединение "падает" в 15-20 случаях из 100. Для этих клиентов создан сервер приложений, который помимо всего прочего реализует передачу(по запросу с клиента) данных которые были изменены В БД с момента предыдущего запроса, а клиент их локально буферизирует.
Клиент есть? Сервер приложений есть? Сервер БД есть? Чем не многозвенка

Добавлено:
Извиняюсь, пока обедал, тут уже все обсудилиArvur и
Sexton

waik
Этот визард уже как-то пытались искать - и тщетно...
То ли борландовцы его специально убрали (вот только зачем?), то ли забыли.
Кстати, видимо туда же делся визард создания ActiveX контрола - осталась только Active Form

Sexton
Arvur
Ок подход я понял и главное, что всё равно всё надо делать ручками, несмотря на распространенность проблемы :)

Спасибо за внимание

OXDBA

Цитата:

Просто я намекал на специфику формулирования ответов на sql.ru.

Да брось. Никакой особой специфики. Разве что вопросы совсем на F1. Я потому там и свечусь редко - пару раз пошумел мало-мало, на Подгорецкого слегка про ADO наехал .


Цитата:

создан сервер приложений, который помимо всего прочего реализует передачу(по запросу с клиента) данных которые были

Не помню как в Fb, а в MS SQL на такое есть репликация сервер-мастер - сервер-слейв. И просто их повязать между собой. У тебя случайно не так? Когда мне чуть не устроили такое "счастье", я туда полез. Но обошлось - посетителей оказалось мало - 3-5 в день, так что там на бумажку, а потом в контору и оформлять .

=============
2All
Я что-то совсем перестаю понимать

Цитата:

1мб данных (5тыс больших записей)

т.е. в 1 записи 200 байт. Ладно. Будем считать ее большой .
Только вот зачем они все сразу на клиенте? Был уже подобный тред, где заказчик-"аналитик" хотел какие-то бешеные выборки. Вылечилось калькулятором. Тут так же: пусть 1 сек. - посмотреть на запись - 1 ч. 23 мин. на 5000. Только на "посмотреть". Т.е. сразу они точно не нужны.
В ADO есть CursorLocation - useClient, CacheSize - по вкусу в записях. Все. В Фибах наверняка тоже похожее есть (ну не помню, а открывать лень).
И сеть странная: около 30кбит пропускная. Модемная, что ли?

xy

Цитата:

я же работаю с ситуацией, когда 1мб данных (5тыс больших записей) передается по сети секунд 5-10, согласитесь на мгновенность не тянет

Если это ограничение сетевого оборудования, то первое, что приходит в голову - трехзвенка со сжатием трафика между клиентом и app-сервером (я в таком случае использовал kbmMW + FastZLib). Напрягает сервер, но резко разгружает трафик.

SergeBS
Ладно шуметь xy уже вопрос снял

Цитата:

Не помню как в Fb, а в MS SQL на такое есть репликация сервер-мастер - сервер-слейв. И просто их повязать между собой. У тебя случайно не так? Когда мне чуть не устроили такое "счастье", я туда полез. Но обошлось - посетителей оказалось мало - 3-5 в день, так что там на бумажку, а потом в контору и оформлят

Нет, не совсем так, но ладно не будем флудить.
Репликация это хорошо(особенно когда у тебя PK - GUID ), но репликация в FB, да еще базы спроектированной без учета репликации, это отдельная тема, если кому интересно можно поднять.

Sexton

Цитата:

Arvur, зачем такие сложности?

К сожалению, минимум для каждого второго продукта, внедряемого в регионах, заказчик просит расчитывать на нестабильность связи.

Arvur, я не спорю с необходимостью решения такой проблемы. Я удивлен способом (сложностью) решения.