Как отобразить результаты запроса с серверной части приложения в клиентской части приложения ?
В серверной части приложения: TIBConnection, TSQLTransaction и TSQLQuery
В клиентской части приложения: TDataSource и TDBGrid
В толстом клиенте все просто, как сделать в тонком клиенте?
Как отобразить результаты запроса в тонком клиенте?
Модератор: Модераторы
nic1982
Вопрос непонятен. Вы же сами написали, что
следовательно нигде кроме как в DBGrid'е Вы отобразить результат запроса не сможете.
Попробуйте более подробно описать, что именно Вы хотите увидеть...
Вопрос непонятен. Вы же сами написали, что
nic1982 писал(а):В клиентской части приложения: TDataSource и TDBGrid
следовательно нигде кроме как в DBGrid'е Вы отобразить результат запроса не сможете.
Попробуйте более подробно описать, что именно Вы хотите увидеть...
Vadim писал(а):Попробуйте более подробно описать, что именно Вы хотите увидеть...
Хочу увидеть данные
Как связать в тонком клиенте TSQLQuery и TDataSource ?
В толстом клиенте просто достаточно указать TSQLQuery в TDataSource.DataSet
Эм. А в клиент сервере по идее это дело связать по tcp\ip или udp, завернув ответ от базы в любую удобную форму и кинув её в клиент, где уже делать с ней чего нужно.
CynicRus писал(а):завернув ответ от базы в любую удобную форму
Хотелось бы увидеть пример или ссылку на уже готовый проект.
Добавлено спустя 7 минут 27 секунд:
Да я могу взять ответ от TSQLQuery как массив, передать его по сети и отобразить данные в TStringGrid.
Но только как то это топорно, не красиво.
С одной записью этот вариант смотрится хорошо, а с массивом данных не очень.
Заверните этот массив в json или XML, пожмите gzip'om...вариантов то тьма.
nic1982
А Вы все компоненты изъятия данных из базы категорически не хотите в одном месте собрать? Тогда у Вас как раз и будет красиво, как Вы хотели - все данные, затребованные в запросе, придут клиенту одной строкой, а уж в массив его переколбасит SQLQuery. И всё будет отображаться просто и незаметно...
Добавлено спустя 5 минут 56 секунд:
Если уж с тонкими клиентами совсем всё ужасающе плохо, у меня как-то был подобный проект. Клиент: процессор Celeron 100 МГц, ОЗУ 16 МБ, клиентская ОС FreeBSD с X11 сервером без рабочих столов. Там часть тонких клиентов работала в качестве удалённого рабочего стола, а часть клиентов, информационный киоск, ничего кроме браузера не имела. Во втором виде клиентов веб-сервер строит таблицу и опять же, незаметно глазу одной строкой передаёт её клиенту. Проблем при этом вообще 0 целых 0 десятых...
А Вы все компоненты изъятия данных из базы категорически не хотите в одном месте собрать? Тогда у Вас как раз и будет красиво, как Вы хотели - все данные, затребованные в запросе, придут клиенту одной строкой, а уж в массив его переколбасит SQLQuery. И всё будет отображаться просто и незаметно...
Добавлено спустя 5 минут 56 секунд:
Если уж с тонкими клиентами совсем всё ужасающе плохо, у меня как-то был подобный проект. Клиент: процессор Celeron 100 МГц, ОЗУ 16 МБ, клиентская ОС FreeBSD с X11 сервером без рабочих столов. Там часть тонких клиентов работала в качестве удалённого рабочего стола, а часть клиентов, информационный киоск, ничего кроме браузера не имела. Во втором виде клиентов веб-сервер строит таблицу и опять же, незаметно глазу одной строкой передаёт её клиенту. Проблем при этом вообще 0 целых 0 десятых...
CynicRus писал(а):вариантов то тьма
Ага, только нормальный всего лишь один.
Придется писать АПИ в котором сделать возможность догрузки данных.
Пример АПИ:
[выполни запрос к справочнику Х с параметрами фильтрации F и сортировки S]
[сколько строк в результате запроса к справочнику Х]
[дай данные с-по из результата запроса к справочнику Х]
В клиенте отлавливать событие когда пользователь будет прокручивать список, для того что бы догрузить данные.
Или выводить постранично, что намного проще в реализации.
Добавлено спустя 14 минут 3 секунды:
или попробовать сериализацию
Добавлено спустя 38 минут 53 секунды:
Vadim писал(а):А Вы все компоненты изъятия данных из базы категорически не хотите в одном месте собрать?
Я Вас не понимаю, приведите пример кода.
Vadim писал(а):а уж в массив его переколбасит SQLQuery
Это выглядит как фантастика.
nic1982 писал(а):Я Вас не понимаю, приведите пример кода.
Вы это серьёзно?
fcl-db/examples
Vadim писал(а):Вы это серьёзно?
Ну это не смешно, где тут
пример клиент серверного приложения ?Vadim писал(а):fcl-db/examples
Примеров клиент-серверного в гугле навалом. В чем проблема с клиента отправить запрос, на сервере выполнить запрос через ZQuery, или любой другой - и пульнуть ответ в клиента? Json, не json - не важно что.
nic1982
Дело в том, что мы тут все не можем понять, что Вы, конкретно Вы, понимаете под "тонким клиентом". В данный момент, по Вашему описанию, тонкий клиент это когда Вы формируете таблицу из десяти столбцов но... пять первых столбцов у Вас формируется на первом компьютере, а пять последних - на втором. Вы спрашиваете "как сделать это НЕТОПОРНО и КРАСИВО", потому что перебегание пользователя от одного компа к другому, чтобы увидеть таблицу целиком - это топорно и некрасиво, а надо чтобы второй комп сам переезжал к первому, где сидит пользователь. Только не говорите, что у Вас ничего подобного. Я специально то что Вы написали изобразил в максимально идиотском виде. 
Почему нельзя совместить компоненты Connection, Query, DataSource и DBGrid на самом тонком клиенте Вы говорить категорически отказываетесь...
Именно так и никак иначе. На всякий случай поясняю (о Ваших знаниях в области БД я уже, честно говоря, начал думать очень плохо ):
- сервер БД - это серверная часть;
- коннект_с_сервером-запрос_данных-отображение_данных - это клиентская часть.
Итого - мы получаем клиент-серверное приложение и ничто иное...
Дело в том, что мы тут все не можем понять, что Вы, конкретно Вы, понимаете под "тонким клиентом". В данный момент, по Вашему описанию, тонкий клиент это когда Вы формируете таблицу из десяти столбцов но... пять первых столбцов у Вас формируется на первом компьютере, а пять последних - на втором. Вы спрашиваете "как сделать это НЕТОПОРНО и КРАСИВО", потому что перебегание пользователя от одного компа к другому, чтобы увидеть таблицу целиком - это топорно и некрасиво, а надо чтобы второй комп сам переезжал к первому, где сидит пользователь.
Только не говорите, что у Вас ничего подобного. Я специально то что Вы написали изобразил в максимально идиотском виде. Почему нельзя совместить компоненты Connection, Query, DataSource и DBGrid на самом тонком клиенте Вы говорить категорически отказываетесь...
nic1982 писал(а):пример клиент серверного приложения ?
Именно так и никак иначе. На всякий случай поясняю (о Ваших знаниях в области БД я уже, честно говоря, начал думать очень плохо
):- сервер БД - это серверная часть;
- коннект_с_сервером-запрос_данных-отображение_данных - это клиентская часть.
Итого - мы получаем клиент-серверное приложение и ничто иное...
А бизнес логику ещё можно и в хранимки вынести...Если конечно база не какой нибудь Access
CynicRus
Access - это то, чем сегодня пугают непослушных программистов ("Будь паинькой, а то всю жизнь будешь работать с Access-БД..." "Нет, шеф, только не это!!!!!!")
Access - это то, чем сегодня пугают непослушных программистов ("Будь паинькой, а то всю жизнь будешь работать с Access-БД..." "Нет, шеф, только не это!!!!!!")
CynicRus писал(а):А бизнес логику ещё можно и в хранимки вынести...
О нет только не это,
это жесткая привязка к конкретной СУБД
и размазывание логики между СУБД и серверной частью.