Unsere Anwendung (Bereich Elektrotechnik) hat ihre Daten in einer DB. Der typische Anwender hat zwar Ahnung von der E-Technik also von der Datenauswertung und der Bedeutung der Daten aber nicht von der DB im Hintergrund und wie solche Auswertungen via SQL erstellt werden.


Gibt es ein Konzept oder .... um möglichst flexibel dem Anwender SQL Abfragen zu ermöglichen , ihn aber nicht mit SQL zu nerven/überfordern?
Ein Memo in welches der Anwender seinen SQL Befehl einträgt und wir dann ein query.execute abfeueren wäre zwar flexibel genug aber nicht bedienerfreundlich.
Für jede mögliche Abfrage ein separates Form zu erstellen könnten wir zwar realisieren bläht die Anwendung auf und ist auch nicht sehr hilfreich.

Hat jemand hier eine Gute Idee ?

Inspirationen in dem Bereich gibt es viele. Das geht bei MS Query im Office-Paket los und bei den unzähligen Business Intelligence Lösungen weiter. Wir geben der Auswertung mit welche Parameter sie benötigt und bauen uns dann entsprechend das Filter-Formular via Code zusammen.

Ich finde für Nicht SQL Kenner sowas wie MS Access Abfrage Formular ganz brauchbar.

Wir setzen etwas einfacheres ein.
- "Admin" User definiert Datenquelle (View) für vermutlich "interessante" Bereiche nach Bedarf, Absprache
- "Admin" User definiert zu einer Datenquelle oben mögliche Parameter (Text, Zahl, Datum, LookUp)
- Anwender ruft Datenquelle auf, die definierten Parameter (plus etwas Kosmetik wie Label, Datetimepicker) werden dargestellt, der Anwender trägt seine Werte ein
- Das Ergebnis wird in Excel ausgegeben
- Als Konvention wird noch ein bestimmtes Makro definiert, wenn in Excel automatisch eine Weiterverarbeitung erfolgen soll.
Alles hängt an einem Rechtemodell, das ebenfalls dynamisch geändert werden kann. Damit werden die Grenzen fließend.

Ich habe ein Set von SQL-Befehlen, die in einem DevExpress-Grid dargestellt werden.
An Parametern habe ich nur einige wenige Unterschiedliche, z.B.:

• Datum Von-Bis (@DateFrom, @DateTo)
• Kostenstelle (@Department)
• Produktgruppe (@ProductGroupID)
• Personalgruppe (@PersonalGroupID)
• Maschinengruppe (@MachineGroupID)
• Schicht (@Shift)

Für jede der Parameter habe ich ein Panel, das genau den einen Parameter (bei der date range zwei) editierten kann.
Die Queries sind in einer TreeView dargestellt. Beim Auswählen eines Knotens wird die Query geladen und die entsprechenden Edit-Panels dargestellt. Dann nur noch die Grobfilter auswählen und Ausführen.

Alle weiteren Details, insbesondere Spaltenanordnung und -sichtbarkeit, Gruppierung und Filterung, Aggregierung (Summenzeilen usw) kann ich mit dem Dev-Express Grid machen. Das jeweilige Layout kann man abspeichern, sodaß man für jede Query beliebig viele Views ablegen kann. Ein Export nach EXCEL ist auch eingebaut.

Neue Queries definiert man in einer Textdatei, die man dann einfach ins Verzeichnis schmeißt.

Zitat von bernhard_LA:

Gibt es ein Konzept oder .... um möglichst flexibel dem Anwender SQL Abfragen zu ermöglichen , ihn aber nicht mit SQL zu nerven/überfordern?

Was spricht gegen entsprechende Filtermasken bzw. Filterformulare? Bis zu einer gewissen Komplexität ist das durchaus im Bereich des Machbaren, finde ich. Bedienerfreundlichkeit kostet nunmal Aufwand an Zeit und Ausdauer.

Viele der Reports/Queries haben >100 Spalten. Da wird das dann aufwändig mit dieser Art der Filterung. Im DevExpress-Grid kann man -wie bei Excel- Spaltenfilter auswählen. Das macht das Grid alles von alleine. Zusammen mit dem Printmanager hat man den Ausdruck (in Farbe! und buunt!) auch gleich dabei.

Ich habe z.B. den Zeitraum-Filter nur deshalb, weil die Gesamttabelle > 1.000.000 Einträge hat. Da wäre das 'Live Filtering' auwändig. Geschweige denn das Laden.

Zunächst gibt es query-Builder wie Sand am Meer. Access is wirklich ganz gut als Frontend zu gebrauchen, wenn die Anforderungen nicht zu hoch liegen. Und views sind eine gute Idee um Komplexität zu reduzieren.

Auf keinen Fall darf man vergessen, daß Simplifizierung gleichzeitig die Flexibilität reduziert.

Gruß
K-H