Здравствуйте

Написал программу по выводу на экран информации из БД. Вывод осуществляется через QSQLQueyModel+QTableView. БД нужна для логирования, поэтому сами данные нередактируемые, к тому же будет заточена под единственного на каждую сессию клиента.
Единственная функция приложения в том, чтобы предоставить пользователю возможность выборки из БД по некоторым критериям. Т.к. потенциальный пользователь с SQL не знаком и знакомится не собирается, думаю самым удобным способом выбора критериев будет выделение мышью или некой комбинацией "кнопка+ЛКМ/ПКМ" нескольких критериев выборки на экранном представлении с последующим формированием запроса. Т.е. если грубо, кликаем на "Фамилию1", кликаем на "Фамилию2", кликаем на "ДатуХ", нажимаем на форме большую кнопку "Применить фильтр" и смотрим на результат.

Общие принципы формирования запросов в БД я знаю, как определять содержимое кликнутой ячейки таблиц (т.е. критерий выборки) тоже вроде по форумам освещено нормально, непонятно как это оптимально совместить в одном месте - запросы в драйвер БД передаются виде строки, где название таблицы и столбцы, по которым будет производится выборка (т.е. в данном случае "Фамилия" и "дата"), вроде должны указываться явно?

Я думал в сторону формирования набора шаблонов, учитывающих все возможные варианты сочетания столбцов, но потом вспомнил комбинаторику и осознал, что для таблицы из 15 столбцов это слишком будет

Если кто сталкивался с подобной проблемой, то буду рад помощи

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

совсем непонятно, зачем у тебя БД с таблицей на экране связана - это разные объекты, друг про друга не знающие

пусть у тебя есть переменная
QString sql;

без фильтра


когда щёлкаешь "фамилия1" , sql у тебя должна принять вид

sql=="select * from table where secondname='фамилия1' ";

когда щёлкаешь ещё "фамилия2"

sql=="select * from table where secondname='фамилия1'  or secondname='фамилия2'";

и так далее

затем ты отправляешь собранный запрос в СУБД , получаешь данные и выводишь на экран

Можно конечно вручную формировать строки запросов и потом как то мэпить параметры подбирая их с UI и где то предварительно храня...
Но на мой взгляд делать вот так вот:

это убожество А если это будут не строковые данные да не под одну СУБД ? Да и не стоит забывать, что что есть escape символы, которые в разных БД разные и их тоже надо как нибудь экранировать и экранируются они обычно тоже по разному...

А можно использовать средства фреймворка
Например QSqlTableModel работает именно на основе данного функционала.

я только путь показал, на пальцах. Не стоит так остро реагировать Дальше - думать

и вот тут поподробнее объясни свой бред


и

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

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

bool preparedStatement - установка этого флага позволяет подготовить многоразовый запрос, в который можно биндить значения.


Сенсей указал путь ? Я думаю, то что нужно генерировать запросы это и так очевидно, ну при условии что объем данных более менее большой, иначе можно было бы использовать прокси модели например. Кстати что на это скажет ТС, каков предполагаемый объем данных?

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

Форматы данных(тех же дат, или например блоб полей) могут отличаться в различных СУБД. (пруф)


не удивительно что в гугле забанили такого не вежливого и некомпетентного человека

я прекрасно знаю всё, о чём тут говорится. А вот ты читать не умеешь Естественно, что я предполагаю сначала сбор данных (не текстов - а просто набор флагов и данных, из чего потом собирать запрос). Когда собирается запрос, всё делается по правилам - и порядок, и экранирование.

Странно, что такие очевидные вещи нужно пояснять