Я работаю над приложением Winforms С# для клиента, который заменяет их старое решение на базе MS Access. Он полностью переписывается и теперь использует SQL Server в качестве своей базы данных. Это программное обеспечение находится на завершающей стадии разработки.
Одна вещь, которую они только что запросили, - это возможность делать пользовательские запросы, которые пользовательский интерфейс программного обеспечения в настоящее время не позволяет им делать в то время, когда он им нужен.
С помощью своего старого решения Access они могут использовать конструктор запросов для создания собственных пользовательских запросов. С решением winforms/Sql Server они не могут этого сделать. Они также не хотят сами писать SQL.
Может ли кто-нибудь подумать о хорошем решении этой проблемы? Возможно, библиотека Winforms, которая позволяет пользователю создавать график бизнес-объектов и "и | или" логику. Или какой-либо другой тип пользовательского интерфейса, который позволяет им настраивать запросы, почти так же, как они могут делать в Access (но, возможно, больше для домена).
Update
Я заметил ответ Якуба как ответ, так как это ближе всего к тому, что я искал в то время. Я закончил, хотя писал для них специальную форму для генерации своих запросов:
В поле "Выбор таблицы..." во второй группе отображаются только те таблицы, которые были добавлены в верхний список.
Так как макет базы данных в значительной степени установлен в камне, я написал код, чтобы разумно рассчитать любые необходимые соединения. Например, если они добавляют две косвенно связанные таблицы в верхней группе, тогда, когда он генерирует SQL, он будет добавлять любые необходимые соединения для их связывания. Если макет базы данных изменился, я очень легко изменил ссылки FK в коде редактора запросов.
Для группы условий управление значением (4-е управление вниз в этой группе) изменяется в зависимости от типа поля (текстовое поле, числовое управление вверх/вниз, датпикер, флажок).
Когда они нажимают "Запустить запрос", они получают другую форму с gridview, отображающим результаты. В этой форме результатов они могут экспортироваться в файл с разделителями табуляции.
Я дал им первую версию этого, и пока они до сих пор довольны.
Я не хотел идти по маршруту доступа, потому что весь смысл этой новой версии программного обеспечения отводит их от Access (ну, не весь смысл, так как там есть еще много функциональности). Это казалось огромным шагом назад, чтобы сохранить эту зависимость с Access там. Это также означает, что если они сохраняют множество пользовательских запросов в Access и я когда-либо изменяю схему базы данных, я, скорее всего, нарушу их запросы. Я не хочу, чтобы у них был доступ к базе данных. На мой взгляд, он просит неприятностей. Единственное, что должно касаться базы данных, это новое программное обеспечение и любые автоматизированные резервные копии баз данных, которые мы делаем - ничего другого, особенно не пользователей!
Другим преимуществом для этого в программном обеспечении является то, что я могу выполнять пост-обработку результатов запроса. Например, существует немало алгоритмов анализа данных, которые выполняются в программном обеспечении, которые написаны в коде .NET. Поэтому я могу добавлять поля к этому интерфейсу, которые позволяют им выбирать результаты этих алгоритмов.
