Office: (Office 2010) Zugriff auf Backend Tabellen sehr langsam

Zu der Anmerkung wg. des UNC-Pfades:
Da dummerweise die betroffenen Kollegen ihre Netzlaufwerke teilweise unterschiedlich verlinkt haben, ist die UNC-Pfadangabe die einzige, bei der ich sicher sein kann, dass sie stimmt.

Zu der Anmerkung wg. dem lokalen Test:
Ich hatte die DB in der ersten Entwicklungsphase lokal auf meinem PC liegen, da gab es keine Probleme.

Zur permanenten Verknüpfung zum Backend:
Ich habe eine Formular das ich unsichtbar öffne dort öffne ich beim Laden des Formulars eine leere Tabelle auf dem Backend.

Zu den Anmerkungen von Rudolf:
Denen werde ich mich dann mal widmen. *Smilie

 

man kann eine neue UNC-Freigabe anlegen, und mit der arbeiten, das berührt die vorhandenen ja nicht. *wink.gif*

 

Hallo
ich weiss nicht wie es bei dir damit steht *wink.gif*

auf Seite 65 zu finden:
Bei der Datenherkunft bei Formularen, Berichten, (Kombifelder etc.) wenn möglich Nicht als
SQL-string angeben sonder diesen SQL speichern als Abfrage!
Michael Zimmermann spricht von bis zu 400% Leistung Steigerung!?
Wenn es unbedingt Dinamisch sein musshilft möglicherweise die
gespeicherte Abfrage mit VBA Dynamisch zu korrigieren
das gilt auch für jegliche Art von SQL aus VBA
eine solche Hilfs-Abfrage könnte helfen die Sql-Strings zu finden
Code:

 

Wenn DU die verwurstelten Kisten der Kollegen kennen würdest ...
Es hat schon seinen Grund, waurm ich über UNC-Pfade gehe, glaube es mir.

 

Hallo!

Andre meinte auch nicht, dass du ein Laufwerk mappen sollst, sondern einen Share in tieferer Ebene nutzen könntest => Im Server auf tieferer Verzeichnisebene eine weitere (eventuell versteckte) Freigabe einrichten (lassen).

mfg
Josef

 

Hallo Rudolf,

das mit den SQL-Strings in Kombos mache ich recht intensiv und es sind auch viele, allerdings ist es so, das die bis auf wenige Ausnahmen auch nur auf Tabellen gehen, die < 100 Datensätze haben. Lohnt sich das dann auch?
Noch eine Frage zur Kombos auf manipulierten Abfragen:
Wenn ich eine Abfrage ändere, muss ich dann die Kombo refreshen?
Ein Prblem mit den Abfragen wäre es nicht, da ich die Basis der jeweiligen SQL-Strings eh schon aus einer Tabelle hole. in diesen Basis-SQLs baue ich dann nur noch die benötigten Abfragebedingungen ein. (Ersetzen von Platzhaltern).

 

Hallo
zu

würde ich Ja sagen
doch (wann, wie, wo) änderst Du die Abfrage ?

dazu:

da sage ich nur Ja immer.

eine Abfrage wiert optimiert ein SQL-String NICHT

Mache einmal eine Abfrage mit dem code den ich Dir oben (#18) angegeben habe und du siehst alle die betroffen sind!

 

Ich muss mich dann doch noch mal zu dem Thema melden, da es mittlerweile unerträglich ist, wenn mehr als ein User die DB benutzt.

Noch mal grundsätzlich:
Wenn nur Ein User mit der DB arbeitet ist alles Prima, sobald es mehr als einer ist, ist die Performance sofort total im Keller.

Das kann doch nichts mit Pfadlängen oder Dateinamen usw. zu tun haben.
Für mich riecht das ja eher irgendwie nach einer Satzsperren-Problematik oder etwas in dieser Richtung.

Oder liege ich da völlig falsch?

 

... die bereits erwähnte LDB-Locking-Problematik hast du schon ausgeschlossen?

mfg
Josef

 

Weitere Anmerkung: Jeder User hat sein "eigenes" (möglichst lokales) FrontEnd oder greifen alle User auf ein gemeinsames FrontEnd (das dann vmtl. nicht lokal liegt...) zu?

 

Hallo,

das gleiche Problem hatte ich auch. Eine "uralte DB" aufgeteilt in FE/BE
FE verteilt an die verschiedenen PC-Stationen und BE an einem PC.
In einem, dem Haupt-Formular bzw. in Unterformular (endlos), waren so viele
Aktualisierungen und DomWerte abgefragt, dass es nicht voran ging.
Jede Eingabe dauerte Sekunden, da alles jedes Mal wieder neu geladen wurde
und so kann man nicht arbeiten.
Ich habe an jenen PC bei denen nicht die BE lag, all das heraus genommen,
das kann man eben jetzt nur mehr an einem PC abfragen, was in diesem Fall kein Problem war.
Aber, die restlichen FE funktionieren super. Man muss eben wissen, was wo eingesetzt werden soll.
Eventuell hilft dir das, um der DB einen Turbo zu verpassen *Smilie

 

So, der Reihe nach:
@josef:
Du meinst mit LDB-Locking diese Geschichte:

Ich hoffe ich habe das Richtig verstanden, ich mache folgendes:
Das FE hat ein Startformular das eine Tabelle im BE öffnet. Dieses Startformular bleibt unsichtbar geöffnet. War das so gemeint?

@Benny:
Alle User haben einen Link auf eine DB, die nichts weiter tut als zu prüfen, ob die aktuelle Version des FE auf dem PC des Users vorhanden ist.
Nach einer eventuell notwendigen Installation bzw. eines Update, wird dann dass FE lokal geöffnet und die Hilfs-DB schließt sich wieder.

@Alfred:
Ich habe mehrere Formulare auf dem FE die auch nicht alle gleichzeitig geöffnet sind. In vielen Fällen kopiere ich die zu bearbeitenden Daten auch zunächst in eine Hilfstabelle, die dann mit dem Formular verbunden ist. Von daher würde ich Deinen Tipp bei mir erstmal nicht anwenden können.

 

...sorry, ist mir zuerst nicht eingefallen, ich habe auch so eine Hilfstabelle erstellt.
und zwar für die Kombi-Felder im UFo, die ja eine Abfrage haben, die auf die Daten der
BE zugreifen.
Habe diese Daten in einer komprimierten Form auf den FE's gespeichert.
Wird das Formular geschlossen, werden diese neuen Daten in der HTabelle gespeichert.
Es sind natürlich auch viele Formularen in dieser zuvor angesprochenen DB vorhanden,
aber nur eines, das echt ein Problem war.
Das alles ist natürlich nur eine Notlösung, eine tolle Sache ist das nicht...

 

\@Alfred:
Ich habe das Problem bei fast jedem Formular.
Beispiel:
Da ist eines mit 2 Datumsfeldern, einem Kombifeld und einem Textfeld.
Alles ungebunden.
Das Textfeld ist ein reines Anzeigefeld.
Jedes mal, wenn ich eines der 3 anderen Felder verändere läuft eine kleine Abfrage, die mit diesen 3 Werten eine Tabelle auf die Anzahl der Treffer abfragt und diese dann im Textfeld anzeigt. Die Quelltabelle hat keine 2000 Datensätze.
Hier dauert es schon mehrere Sekunden um ein Ergebnis zu bekommen. Aber immer nur dann, wenn mehr als 1 User die DB geöffnet hat.
Gut, dieses Abfrage wird zwar suboptimal vie ExecuteSQL ausgeführt aber wenn das so schlimm wäre, dann müsste es immer langsam sein, denke ich.
Ich spiele gerade mit dem Gedanken, das BE auf eine SQL-Server-DB zu verlagern und die Abfragen dann, soweit möglich dort laufen zu lassen.

Was ist da besser, den View als Tabelle ans BE binden oder Path Through-Abfragen verwenden?
Gibt es da Unterschiede in der Performance?

 

...na ja, da hast du dein Problem schon im Visier, diese Daten werden jedesmal
abgerufen und neu aufbereitet, das dauert seine Zeit.
KA wie deine DB aussieht, möchte mir auch kein Urteil darüber bilden, da ich sie ja nicht kenne,
aber bin überzeugt, dass da etwas schief läuft...
und an dem DB-Modell ist vermutlich auch nichts mehr zu rütteln, passt da alles... wieso ungebundene Felder?
Ist da ev. ein Problem der dauernd wiederkehrenden Abfragen bei Eingaben?!