Endlosformular: Gleiche Filter nach Requery

[Holger69]

Hallo Zusammen,

Ein Endlosformular ist an eine PassThrough-Abfrage (MS SQL-Server) gebunden.
 
Es enthält neben den Datenfeldern zusätzlich einige Befehlsschaltflächen.
Diese  Befehlsschaltflächen öffnen kleinere Pop-Up-Formulare, über das der User Daten eingeben bzw. ändern kann.

Damit die Änderungen im Endlosformular nach dem Schließen des Pop-Ups sichtbar werden, löse ich ein Requery des Formulars aus (Forms!frmEndlos.Requery)

So weit, so gut.

Üblicherweise filtert der User aber vorher das Endlosformular über das Kontextmenü (Rechtsklick)
Allerdings wird durch das Requery des Formulars (Requery der PassThrough-Abfrage) wieder die komplette, ungefilterte Menge an Datensätzen angezeigt.

Wie erreiche ich, dass die Filtereinstellungen vor dem Öffnen des Pop-Ups auch nach dem Requery wieder im Formular wirken?

Vielen Dank im Voraus!

Gruß,
Holger

[markusxy]

Eine Passthrough Abfrage für ein Endlosform - Kann ich nicht sagen, habe ich nie verwendet.
Wie kommt man auf die Idee so zu arbeiten - die Daten kann man ja nicht bearbeiten?
Das ist doch ein völliger Krampf.

Warum verwendest du keine verknüpfte View?
Da hast du eine perfekte Zusammenarbeit mit dem Server und es ist genauso performant.

Bei einer Prozedur verwende ich dann eher ein ADO Recordset.
Alles besser wie Passthrough.
Allerdings muss man dann selbst für den Filter sorgen - aber ADO kann ja das Recordset filtern.

[Beaker s.a.]

Hallo Holger,

Wie erreiche ich, dass die Filtereinstellungen vor dem Öffnen des Pop-Ups auch nach dem Requery wieder im Formular wirken?

Filterstring in einer Variablen zwischenspeichern und nach dem Requery damit wieder einstellen.

gruss ekkehard

[Holger69]

Eine Passthrough Abfrage für ein Endlosform - Kann ich nicht sagen, habe ich nie verwendet.
Wie kommt man auf die Idee so zu arbeiten - die Daten kann man ja nicht bearbeiten?
Das ist doch ein völliger Krampf.

Selbst auf die Gefahr, dass ich jetzt in Ungnade falle, aber muss das denn wirklich sein?
Es geht doch nicht darum, ob eine Pass-Through-Abfrage die geeignete Wahl ist, sondern um die Fragstellung nach der Filtereinstellung!

Ich habe mich an Jungblut/Minhorst "Access und SQL-Server" Kapitel 14.3 orientiert und auf minimale Lesesperren gesetzt. Vielleicht ist es nicht der beste Weg, aber ich bin bislang sehr gut und schnell damit gefahren.

@Beaker s.a. : Danke schön, so hab ich's mir gedacht.
Am besten gar eine Public Function, die für beliebige Filtereinstellungen benutzt werden kann, je nachdem, was auf dem Formular so los ist. Wäre dies aus Deiner Sicht zielführend?

[Beaker s.a.]

Ich denke schon.
Die Profis würden wahrscheinlich eine Klassenprogrammierung
"empfehlen".

[Holger69]

So, erledigt und funktioniert super
Zunächst eine Public-Anweisung deklariert

Code [Auswählen] Erweitern

Option Compare Database
Option Explicit

Public FilterSetString As String
Danach eine Public Function, die diese Variable mit dem Filter-String vom Formular kommend befüllt.

Code [Auswählen] Erweitern

Public Function FilterSetting(FilterString As String)
        FilterSetString = FilterString   
End Function
Auf dem Endlosformuar wird beim Öffnen des Pop-Up nun der eingestellte Filter (falls es einen gibt) an die Public Function übergeben

Code [Auswählen] Erweitern

If Not IsNull(Me.Filter) Then
       FilterSetting Me.Filter
End If
Kommt man vom Pop-Up nach dem Requery zum Formular zurück, wird der Filter mit 

Code [Auswählen] Erweitern

Form_frmEndlos.Filter = FilterSetString
Form_frmEndlos.FilterOn = Truewieder hergestellt

[Beaker s.a.]

Uups, jetzt habe ich aber Mist geschrieben, daher gelöscht.
Ich würde das mit der öffentlichen Variablen so nicht machen.
M.E. besser ist hier die Verwendung einer Property, die den Zugriff
von aussen kapselt. Also in einem allgem. Modul

Code [Auswählen] Erweitern

Option Compare Database
Option Explicit

Private m_FilterString As String

Public Property Let Filterstring(NewFilterString As String)
    m_FilterString = NewFilterstring
End Property
Public Property Get Filterstring() As String
    FilterString = m_Filterstring
End PropertyUnd dann, von wo auch immer

Code [Auswählen] Erweitern

If Not IsNull(Me.Filter) Then
       FilterString = Me.Filter
End Ifbzw.

Code [Auswählen] Erweitern

Form_frmEndlos.Filter = FilterString

[markusxy]

Es geht doch nicht darum, ob eine Pass-Through-Abfrage die geeignete Wahl ist, sondern um die Fragstellung nach der Filtereinstellung!

Ich weiß natürlich nicht, ob du reiner Copy & Paste Programmierer bist, oder ob du schon so weit bist, dass du Technologien entsprechend der Anforderung einsetzt.
Du könntest ja auch offen für Überlegungen sein, wo es in die Richtung geht.

PassThrough zwingt einen ja zu einer mehr als umständlichen Arbeitsweise.
Die ganzen unnötigen Schritte -> Popup Form für Datenerfassung/Änderung und dann Daten neu einlesen und dann Daten wegen dem Filter erneut einlesen - bei so was stellt es mir die Haare auf - nicht nur wegen der unnötigen Last auf dem Netzwerk.

[Holger69]

Ich weiß natürlich nicht, ob du reiner Copy & Paste Programmierer bist, oder ob du schon so weit bist, dass du Technologien entsprechend der Anforderung einsetzt.

Warum diese fiese Polemik, lieber Markus? Hattest Du einen schlechten Tag? Warum nicht gute Ideen von anderen übernehmen? Deinen Tip mit dem "Cross Apply" von neulich fand ich super! Genau das ist doch der Grund, weshalb man in einem Forum nach Rat sucht.

PassThrough zwingt einen ja zu einer mehr als umständlichen Arbeitsweise.
Die ganzen unnötigen Schritte -> Popup Form für Datenerfassung/Änderung und dann Daten neu einlesen und dann Daten wegen dem Filter erneut einlesen - bei so was stellt es mir die Haare auf - nicht nur wegen der unnötigen Last auf dem Netzwerk.

Es ist keine Beratungsresistenz gegen Neues. Ich bin lediglich von deiner technischen Argumentation nicht überzeugt. Ich bin sogar sicher, dass der Weg, den ich mit der PT-Abfrage gehe, sogar den geringstmöglichen Datenverkehr im Netzwerk erzeugt. Und ich will erklären, warum - falls es jemanden interessiert.

Eine PT-Abfrage zieht über eine gespeicherte Prozedur auf dem SQL-Server die Daten für das Endlos-Formular. Hier würde die verlinkte Tabelle/View ebenfalls die Daten ziehen, also kein wirklicher Unterschied.
Der optionale Filter wird über das Formular gesetzt -> kein Traffic im Netz, weil die PT-Abfrage nicht erneut ausgelöst wird. Ich weiß nicht, ob bei der verlinkten Tabelle/View an dieser Stelle neu eingelesen würde (->Traffic)
Das Pop-Up zum Bearbeiten wird, sofern Daten vorhanden sind, mit Werten aus dem aktiven Datensatz des Endlosformulars befüllt -> kein Traffic im Netz.
Der User geht im Pop-Up völlig ohne Netzwerkbelastung von einem ungebundenen Feld zum nächsten. Erst wenn er am Ende "speichert", werden die Inhalte der Felder eingesammelt und es kommen lediglich zwei SQL-Strings per PT-Abfrage an den SQL-Server. Der Erste mit der Aktionsabfrage, der Zweite für das Requery.
Falls der User nichts ändert, macht er das PopUp einfach zu. Das Endlos-Formular benötigt dann auch kein Requery und Filter bleiben, wie sie waren -> kein Traffic
Ich wüsste wirklich nicht, wie man hier noch netzwerk-effizienter vorgehen kann, außer man lässt den User das Requery manuell durchführen, weil er keinen Wert auf eine automatisch aktualisierte Anzeige legt.

Bei den verlinkten Tabellen/Views gibt es natürlich den Vorteil, dass man direkt in die gebundenen Felder tippt. Doch jedes Mal, wenn der User von einem gebundenen Feld zum nächsten geht, gibt es Verkehr auf der Leitung. Und wenn der User sich 'nen Kaffee holt, während sein Cursor in einem Textfeld blinkt...? Ich weiß nicht, wieviele Pings da zusammen kommen. Mein Pop-Up sorgt jedenfalls für (mehr) Ruhe im Netzwerk.

Du könntest ja auch offen für Überlegungen sein, wo es in die Richtung geht.

Bin ich! Du auch?

[markusxy]

Warum diese fiese Polemik, lieber Markus?

Das war eigentlich ernst gemeint.
Es gibt nur Rückmeldungen bei kopierfertigen Vorlagen - ansonsten kommt nichts.

Der optionale Filter wird über das Formular gesetzt -> kein Traffic im Netz, weil die PT-Abfrage nicht erneut ausgelöst wird.

Das würde mich wundern, wie kommst du zu der Erkenntnis?
Hast du das via SQL Profiler geprüft?

Ich meine, wenn das so wäre, wäre es spannend.
Bei einem ADO Recordset, wie ich es bei SP's verwende gibts jedenfalls sicher keinen Trafik beim Filtern, weil das ADO.Recordset bei einem Client Cursor nunmal filtern und sortieren kann.