Mahlzeit,
ich hab schon einiges gelesen, aber bin noch nicht ganz schlau daraus geworden.
Ich hab mein Access Backend zum MS SQL Server gewechselt. Bin in Sachen SQL Server noch Anfänger.
Ich bin auf der Suche nach der schnellsten Verbindung zum SQL Server je nach Anwendungsfall.
Nicht änderbare Abfrage:
Da nutze ich eine gespeicherte Prozedur mit Parametern auf dem SQL Server und greife mit einer PathThrough Abfrage, die ich über VBA anpasse, zu. Klappt recht fix.
Aktionsabfragen handhabe ich genau so.
Jetzt der für mich unklare Punkt!
Ich habe ein Formular was ich mit einem Datensatz vom SQL Server binden will, bedeutet ich möchte Daten ändern können.
Mir schwirren zwei Methoden vor.
Tabelle mit ODBC verlinken und das Formular daran binden. Ist ja dann änderbar.
oder
Mit ADODB ein Datensatz in ein Recordset laden und dieses das Formular zuweisen. Ist das aber dann noch änderbar?
Kann man eine gespeicherte Prozedur aus dem SQL Server bearbeitbar direkt wie eine Tabelle in Access verlinken, oder geht das immer nur über PathThrough?
Gibt es da noch eine andere schnelle Art?
Hoffe ich könnt mir da etwas Klarheit schaffen.
Grüße
Moin,
hier (https://www.access-o-mania.de/forum/index.php?topic=23773.0) hab ich nun gelesen, dass man ein RecordSet mit ADODB bearbeitbar ein Formular zuweisen kann.
Wird die Join-Logik dann im SQL Server durchgeführt, oder in Access?
Hab gelesen, dass es im SQL Server schneller geht. Der SQL Server analysiert/optimiert das ja und speichert sich das irgendwie ab. Ist das bei dieser Variante auch, oder nur bei Views und SP die auf dem Server angelegt werden?
Grüße
Zitat von: Xoar am Juni 16, 2021, 11:06:05Wird die Join-Logik dann im SQL Server durchgeführt, oder in Access?
Bei einer direkten Verbindung zum Server, ist das wie bei DAO-PassThrough.
Die gesamte Verarbeitung findet am Server statt.
Nur mit dem Vorteil, dass auch das Recordset basierend auf einer View, Prozedur oder SQL String bearbeitbar ist (soweit technisch möglich).
Zitat von: Xoar am Juni 16, 2021, 11:06:05Der SQL Server analysiert/optimiert das ja und speichert sich das irgendwie ab. Ist das bei dieser Variante auch, oder nur bei Views und SP die auf dem Server angelegt werden?
Sobald es eine Where Bedingung gibt, wird das meines Wissens bei jeder Ausführung analysiert - auch wenn bereits ein Ausführungsplan gespeichert ist. Wenn du einen SQL-String an die DB schickst, dann wird für diesen bei der ersten Ausführung auch ein Plan erstellt, der dann für die nächste Verwendung im Cache bleibt.
Hallo Markus,
alles klar, ADODB lässt den SQL Server arbeiten, sehr gut.
——
Ok, wie lange der Ausführungsplan im Cache bleibt, regelt der SQL Server vermutlich selbst.
Danke 👍🏻
Zitat von: Xoar am Juni 25, 2021, 10:25:14Ok, wie lange der Ausführungsplan im Cache bleibt, regelt der SQL Server vermutlich selbst.
Jein.
Einerseits ja, natürlich.
Anderseits hat der Entwickler indirekt schon einigen Einfluss darauf.
Wenn du in VBA deine SQL-Statements mit hardcodierten Werten zusammenbaust, ist das SQL für jeden Wert ein neues SQL-Statement mit eigenem Ausführungsplan.
Beispiel 1:
SELECT Nachname FROM Kunden WHERE Id = 1;
SELECT Nachname FROM Kunden WHERE Id = 2;
SELECT Nachname FROM Kunden WHERE Id = 3;Das sind drei verschiedene Statements,
jedes hat einen eigenen Ausführungsplan,
die Wahrscheinlichkeit, dass ein Ausführungsplan mehrfach verwendet wird, ist gering, weil er
a) nur für eine konkrete Id gilt, und
b) durch die Vielzahl der Statements ein Ausführungsplan viel schneller wieder aus dem Cache fliegt.
Beispiel 2:
SELECT Nachname FROM Kunden WHERE Id = @KundeId;Dieses SQL hat nur einen Ausführungsplan, egal für welche @KundeId es aufgerufen wird.
Die Wahrscheinlichkeit, dass dieser Ausführungsplan mehrfach verwendet wird, ist groß weil er
a) für jede Id gilt, und
b) dadurch dass es weniger verschiedenen Statements gibt, jeder Ausführungsplan länger im Cache bleibt.
Für die obigen Beispiele, bei denen man davon ausgehen kann, dass Kunden.Id eindeutig ist, ist es sinnvoll, wenn ein und derselbe Ausführungsplan so häufig wie möglich wiederverwendet wird.
Wenn man ein Kriterium hat, dass je nach aktuellem Parameterwert entweder 1 oder 100.000 Datensätze matcht, dann ist es weniger wünschenswert, immer denselben Ausführungsplan zu verwenden.
Super danke für diese Antwort!
Ich nutze die Variante 2 mit dem @Übergabeparameter.