Juni 24, 2021, 20:59:19

Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!


Abfragen und Steuerelemente speichern

Begonnen von Xoar, April 06, 2021, 14:47:21

⏪ vorheriges - nächstes ⏩

Xoar

April 06, 2021, 14:47:21 Letzte Bearbeitung: April 06, 2021, 15:00:07 von Xoar
Hallo an Alle,

bräuchte ein paar Tipps wie ich mein Vorhaben am besten umsetzten kann.

Ich habe über eine Filterklasse (erzeugt einen SQL String anhand der Werte von Steuerelementen).
Man kann sich das so vorstellen, dass es ein Formular mit zig Steuerelementen hat, wo man anwählen kann welche Bedingungen das Abfrageergebnis haben soll. Z.B. Geschlecht = Weiblich und Wohnort = Berlin... so kann der User seine Abfrage sehr dynamisch gestalten.
Das klappt auch alles super, jetzt kommt aber das ABER.
Es wäre schön wenn man die Werte der ausgewählten Steuerelemente speichern kann. Damit man sie bei Bedarf erneut als Schnellauswahl nutzen kann.
Alle Filter-Steuerelemente haben als Präfix ein fil im Namen.

Ein Gedanke war mit einer Schleife alle Steuerelemente zu durchlaufen und die Steuerelementenamen mit Wert in einer Tabelle zu speichern.
Sprich eine Tabelle mit einer ID für die gesicherte Abfrage und für jedes Steuerelement ein DS mit Name und Wert.
TblQrySaved
-QrySavedId
-AbfrageID
-SteuerelementName
-Wert

Dann könnte man bei der Schnellauswahl mit einer Schleife alle passenden Datensätze durchlaufen und die Steuerelemente auf die richtigen Werte stellen.

Den Filter kann man dann ja ganz normal starten, oder am Ende der Schleife automatisch starten.

Habt ihr da eine bessere Idee, oder Verbesserungsideen?

Grüße

ebs17

Du könntest schlicht den gesamten Filterstring nebst einem aussagefähigen Filternamen in einer Tabelle ablegen.
Mit freundlichem Glück Auf!

Eberhard

Xoar

Ja,
hatte ich auch überlegt, nur müsste man dann für eine kleine Änderung im Gesamtfilter, jedes Steuerelement neu setzen.

Wäre natürlich einfacher umzusetzen.
Wird meine Alternativlösung.

Da es ja grundlegend keine wesentlich bessere Speichervariante gibt, werde ich mich mal daran versuchen.

Danke bis dahin 👍🏻

ebs17

Zitatnur müsste man dann für eine kleine Änderung im Gesamtfilter, jedes Steuerelement neu setzen
Für eine kleine Änderung muss man alles ändern?
Ein Filter ist auch nur ... Text. Über eine "Textverarbeitung" (RegEx?) könnte man kleine Änderungen vornehmen.

Ursprünglich nahm ich ja an, Du wolltest genau den gesetzten Filter später wiederholen.

Zitatüber eine Filterklasse
Wenn diese intelligent ist, könnte man über diese nicht nur einen Filterstring zusammensetzen, sondern zusätzlich auch die Filter-Einzelteile in eine Tabelle ablegen.
Mit freundlichem Glück Auf!

Eberhard

crystal

April 07, 2021, 07:50:56 #4 Letzte Bearbeitung: April 07, 2021, 07:57:03 von crystal
Hallo Xoar,

ich denke, du hast ein ungebundenes Formular mit all den fil-Steuerelementen und einen Button "Jetzt SQL bauen".
Warum also baust du nicht eine Tabelle mit all den fil-Steuerelementen als Tabellenspalten und speicherst alles unter einem "Template-Namen" (inkl. Template-Id, zusammengesetztem SQL-String und einem "netten" Beschreibungsfeld)? Formular an diese Tabelle binden - und fertig ist die Kiste. Ich hab sowas schon ein paar Mal implementiert - funktioniert prima. Du brauchst dann auch nicht extra "fil" als Präfix. Einfach die Steuerelemente wie gewohnt benennen mit den üblichen Präfixen (txt, cbo, lst, btn usw.). In den anderen Formularen kannst du dann via Kombobox "Suchmuster auswählen" schlicht auf diese Templates zugreifen und den SQL-String z. B. als 0cm breite Spalte der Kombobox holen.

Auch verschiedene Template-Arten könntest du so speichern (jeweils eigene Template-Tabelle), sofern es nicht zu viele sind. Aber ich denke, es geht eher darum, Templates zu speichern, die verschiedene Werte oder Wert-Teile (mit *) der Zieltabelle speichern soll, z. B. "Alle Datensätze, bei denen der Name mit A beginnt und Geschlecht W ist" oder "Alle Datensätze mit Orts-PLZ 12345 und Anlegedatum ab 01.01.2021".

Im Template-Formular kannst du auch schlicht den SQL-String nutzen , um zum Testen ein Recordset rstTest ReadOnly zu öffen und dem Anwender dann zu informieren, etwa "Diese Abfrage liefert aktuell x Datensätze" (rstTest.GoToLast, x = rstTest.RecordCount).

Auch böte sich an, die Zieltabelle einfach zu kopieren (nur Struktur) unter dem Namen "Zieltabelle_Templates" und daraus dein Suchmuster-Formular zu bauen. Dann hättest du gleich alle gewünschten Felder der Zieltabelle zur Verfügung und kannst die nicht benötigten Felder aus der Template-Tabelle entfernen.

Noch ein Tipp: beim Zusammensetzten des SQL-String braucht man ja öfter das Zeichen ". Ich mache es oft so, dass ich statt " zunächst das Caret-Zeichen ^ benutze und am Ende einfach mit Replace ersetze. Macht die Sache etwas einfacher und du brauchst nicht diese """-Sequenzen oder chr(34)... Oder du definierst eine Konstante mit "Const c34 as string = """").

Gruß,
crystal
Wer Fehler in meinen Antworten findet, darf sie behalten, muss sie aber kommentieren. ;-)
Dies ist keineswegs arrogant gemeint, sondern soll nur unterstreichen, dass meine Antworten - natürlich - nicht immer fehlerfrei sind und sein können.
Devise: bitte immer erst selbst probieren!

Aus gesundheitlichen Gründen nur noch selten dabei...

Xoar

April 07, 2021, 11:25:36 #5 Letzte Bearbeitung: April 07, 2021, 11:39:13 von Xoar
Moin,

stimmt das ist auch eine sehr interessante Variante.

Gefällt mir sehr gut mit dem gebundenen Formular.

So werd ich es machen, gespeicherte Templates inkl. SQL Filterstring in der Tabelle speichern, alle Steuerelemente gebunden.

Dann brauch ich die Filterklasse nur einmalig beim Speichern und bei neuen Filterstrings nutzen. <- Dann brauche ich den Filterstring nicht selber schreiben, dafür ist die Klasse ja da.


Danke euch beiden für die Tipps.


PS: mal was anderes...
Ich plane wegen der Datensicherheit das Backend in Laufe des Jahres auf einen Microsoft SQL Server umzuziehen. Da habe ich bisher aber noch kein Plan von, außer das es ne ODBC Verbindung mit gelinkten Tabellen wird.  🙈 klappen dann noch so Filter SQL Strings über VBA, oder muss das dann anders gelöst werden?




ebs17

Wenn das auch performancemäßig Sinn machen soll, sollte der SQL Server nicht nur als Container für Tabellen dienen (dann wird nämlich der Spaß eher langsamer), sondern er sollte selber arbeiten. Er kann das gut.

Gut angelegtes Geld: Access und SQL Server
Mit freundlichem Glück Auf!

Eberhard

Xoar