Office: (Office 2010) Alternative für temporäre Tabelle

Hallo zusammen,

ich dachte, ich hätte das Thema vorhin schon geöffnet. Komisch.

Also: Ich habe temporäre Tabellen in meine Lösung eingebaut.
Bei einer Tabelle werden z.B. Abfrageergebnisse aus 3 Tabellen zusammengefasst und dann dem User durch Ansicht der Tabelle komprimiert visualisiert. Somit muss er nciht in 3 Tabellen nachschauen.

Wenn nun 2 User gleichzeitig die Funktion ausführen, kann es zu einem Konflikt kommen.

Gibt es dafür eine andere Lösung?
Habe das Thema so aufgebaut, da ich (denke ich zumindest) nicht 3 Tabellen in einer Abfrage sinnvoll abfragen kann und dann noch gruppieren kann.

Oh Gott, hoffentlich ist das verständliche. *wink.gif*

Gruß
Michael

:)

 

Hallo Michael,

bei einer Anwendung, die in Frontend und Backend aufgeteilt ist, wobei das Frontend jeweils lokal auf dem Anwender-PC installiert wird und das Backend sich für den gemeinsamen Zugriff im Netzwerk befindet, sollte das eigentlich kein Problem sein.

Ob dein Konzept mit den temporären Tabellen an sich sinnvoll und/oder notwendig ist, lässt sich so einfach natürlich nicht beurteilen.

 

Du könntest beim Starten der DB für diesen Zweck lokal ein temporäres Backend anlegen (jeder Benutzer hat damit dann sein eigenes lokales Backend) und beim Schließen der DB wieder löschen. Deine temporären Tabellen lagerst Du dort hin aus und verknüpfst sie im Frontend.

 

Die Anfrage von Maggie kann ich nur unterstützen: wenn das Ding ordentlich aufgebaut ist (ein BackEnd und jeder User sein FrontEnd), kann es überhaupt keine Probleme geben.

Warum aber überhaupt eine temporäre Tabelle?
Wenn es nur um die Visualisierung geht, reicht doch eine Abfrage völlig ...

@Nouba: Deinen Vorschlag mit einem kompletten lokalen temporären BackEnd halte ich - mit Verlaub - für ziemlich aberwitzig. Wozu soll das denn gut sein?

 

Ich halte die Idee für ziemlich gut. - Ich habe sogar mal eine eigenen Klasse programmiert, die eine einfache Schnittstelle für sowas abbildet. - Muss ich mal ausgraben.

Das eigene, lokale Backend ist sinnvoll, weil du darin beliebige temporäre Objekte anlegen kannst ohne dein FE damit aufzublähen. Nachdem dein Prozess abgeschlossen ist, löscht du einfach das lokale Temp-Be.

Ich habe das für einen umfangreichen Datenimport mit komplexen Transformationen und Datenbereinigungen benötigt. In nur einem Durchlauf dieses Prozesses ist die DB um mehrere 100MB gewachsen. Da ist es sehr hilfreich, wenn man den Ballast im laufenden Betrieb los werden kann ohne das FE zu komprimieren.

 

\@Hans-Christian,

wenn eine individuelle Abfrage schnell genug ein Ergenisse liefert, stimme ich mit Deinem Humor überein - wenn nicht, stellt für mich die o.g. Methode ein probates Mittel dar, Wartezeiten zu reduzieren. Materialized Views gibt's ja bei Access nicht. Oder vielleicht will man auch nur ein Sternschema anlegen.

 

Ich würde die Aussagen von Nouba und sonic8 unterstreichen wollen.

- Im SQL Server gibt es auch temporäre Tabellen und einen eigene Datei dazu. Warum soll man so etwas in sinnvoller Anwendung nicht nachnutzen?
- Hat man einmal seine Temp-Backend-Lösung stehen, gibt es da auch schnell mehrere Nutzungen als die eine oben genannte Tabelle.
- Wer darauf bedacht ist, sein Frontend zu komprimieren, hat sicher nicht im Kopf, Indexbäume neu zu ordnen und Tabellenstatistiken zu aktualisieren, sondern er will Datenmüll loswerden. Müll im eigenen Topf macht Sinn.
- Abfragelösungen haben, auch bei gutem handwerklichen Geschick, durchaus auch Grenzen hinsichtlich Performance. Wenn man Zwischenergebnisse speichert und diese als Tabelle weiternutzt und gar deren Felder nachindiziert, z.B. weil man Ergebnisse berechneter Felder zum Verknüpfen/Filtern braucht, dann ist ein solches Temp-BE sehr hilfreich. Immerhin hat man mit dem Terminieren dieses Backends nach Beendigung der Nutzung einen akzeptablen Kompromiss in der Form, dass berechnete Ergebnisse dann doch nicht (dauerhaft) gespeichert werden und so Ursache für Datenanomalien sein können.

Ja bitte.

Das wollen wir an der Stelle mal glauben und nicht erwarten, dass da Fehler im Datenmodell oder größeres Unwissen in Abfragegestaltung im Spiel sind.

Die Alternative für eine gemeinsam genutzte Tabelle wäre also eine eigene temporäre Tabelle, sinnvollerweise in einem eigenen temporären lokalen Backend. Dass jeder Nutzer sein eigenes (lokales) Frontend hat, setzt man einfach als Selbstverständlichkeit voraus: Hintergründe zur Arbeitsweise von Access

 

Hallo!

Das kann auch bei 2 Formular-Instanzen eines Formulars auftreten, wenn darin eine Temp-Tabelle benötigt wird.
Abhilfe: Eine "Session"-Kennung als Datenfeld in der Tabelle verwenden. Ich verwende dafür gerne einen GUID-Wert.
In einem Temp-Backend wird das etwas einfacher, da man dann für jede Session eine eigene Tabelle nutzen kann. (Für ein Formular eignet sich dann auch der ObjPtr des Formularinstanz ganz gut als Kennung für die eindeutige Zuordnung.)

Typische Verwendung einer Temp-Tabelle im TempBackend: Mehrfachauswahl in einem Endlosformular. Die markierten Datensätze speichere ich in die Temp-Tabelle und damit sich das Frontend nicht unnötig vergrößert, verwende ich eine temporäre Access-Datei.

Ich verwende für meine Temp-Backends die Klasse TempDbHandler.


mfg
Josef

 

OK. Lieben Dank für die Inspirationen. Sicher sind temporär Tabellen je User besser. Wollte alle Tabellen auf den SQL Server packen, aber dann gibt es halt Ausnahmen. Ich werde die Problemstellung am WE mal speziell für Eberhard heir einspielen. Vielleicht gibt es ja wirklich eine Lösung, die ich nicht kenne. Die kennt man ja erst, wenn man sie kennt. *wink.gif*

Vielleicht mache ich ja tatsächlich auch einen grundlegenden Fehler im Aufbau des Konzeptes. Ca. 15 User sollen Frontend verwenden. Ich kopiere dann in der Regel das Frontend 5x, da meist nicht gleichzeitig alle darauf zugreifen reicht das dann. Ansonsten ist der Aufwand bei Änderungen im Frontend ja immens....

Gruß
Michael

 

Hallo Michael,

Die Frontends gehören auf die Clients.

Nöö, eigentlich nicht. Du hast eins für die Entwicklung, und das verteilst du
über den Server mit einem Versionscheck auf die Clients. Passendes Beispiel
findest du hier: http://www.ms-office-forum.net/forum...hlight=updater

gruss ekkehard

 

Hallo!

Wenn du einen SQL-Server verwendest, könntest du auch dort mit Prozeduren server-seitig die Auswertung erstellen und an den Client nur noch das Ergebnis schicken.

mfg
Josef

 

Ich habe Josef so verstanden, dass das temporäre lokale BackEnd lediglich für die zur Laufzeit notwendigen Tabellen angelegt wird.
Das kann ich noch nachvollziehen - und es ist sicher einfacher, dieses BackEnd am Ende der Sitzung komplett zu löschen als die temporären Tabellen im FrontEnd zu erstellen mit der Maßgabe, das FrontEnd laufend komprimieren zu müssen.

Vorher war hier allerdings von einer lokalen Kopie des kompletten BackEnds die Rede - oder ich habe das falsch verstanden. Dies kann ich mir allerdings nur schwer vorstellen, denn dabei bleibt ja wohl die Synchronisation aller lokalen BackEnds auf der Strecke, zumal wird es kribbelig, wenn mehrere Clients gleichzeitig arbeiten und dabei neue Datensätze im lokalen BackEnd anlegen sollten.

Ich persönlich setze seit geraumer Zeit vorwiegend aktive DBMS als BackEnd ein und lagere einen großen Teil der Geschäftslogik dorthin aus. Dabei sind - wie Josef empfiehlt - serverseitige Funktionen sowie Views und Prozeduren, die diese verwenden, die Objekte meiner Wahl.

 

Früher haben wir auch die Temptabellen im Frontend erstellt und wieder
gelöscht. "Beim Schließen komprimieren" führte öfter dazu, dass
User, die vermeintlich "was vergessen" hatten, genau zu dem Zeitpunkt die
jeweilige Anwendung erneut starten wollten.

Dabei kam es mitunter zu Problemen. DB1 fertig, aber noch nicht umbenannt etc. Darüberhinaus zeigte sich, dass trotz regelmäßigen RepKomps die Frontends allmählich trotzdem erheblich größer wurden. Auch /decompile hat daran nichts geändert. So mussten wir ab und an neue Frontends verteilen.

Die Lösung mit den lokalen Temporärbackends war letztlich die einzig praktikable. Front- und Serverbackend nicht belastet, kein Aufblähen und akzeptable Performance sind seit mittlerweile vielen Jahren bei den reinen Accessanwendungen, die Temptabellen benötigen, das Ergebnis.
Wem das mit dem Erstellen des Tempbackends zum Sessionstart zu lange dauert, kann ein leeres vorhalten und zum Sessionstart mittels Batch oder auch Shell kopieren und mit dem korrekten Namen versehen.

 

Hallo,

so wie ich das sehe, hast du das wohl tatsächlich falsch verstanden.

Auch ich habe bereits gute Erfahrungen mit temporären "Datenbanken" (=Access-Backends) gemacht.

Die Notwendigkeit einer solchen Vorgehensweise lässt sich sicherlich in keinem Lehrbuch finden, sondern ist lediglich den nicht immer optimalen Anforderungen und gegebenen Umständen einer realen IT-Umgebung geschuldet.

Meine Quelle hatte ich damals folgendermaßen dokumentiert:

Vielleicht hilft das (evtl. auch Eberhard?) bei der Suche nach dem Thread.

 

Hallo zusammen,

von Euren Lösungen bin ich im Moment noch weit entfernt....
Nehme das alles aber mit und schaue, wie das geht.

Da ich das in den nächsten Wochen nicht umsetzen kann, hier zurück zu meinem Eingangsproblem: Kann ich die Abfragen auch aufbauen, ohne eine temporäre Tabelle anlegen zu müssen? Worum es geht, habe ich in der DB anbei dargestellt. Letztlich soll der User sehen, wo er alles involviert ist. Das wird in der Abfrage ausgegeben (im Frontend natürlich über ein hübsches Formular). Da die Info's aber aus 4 verschiedenen Tabellen kommen, bin ich halt den Weg über die Datensammlung in einer tmp_tabelle gegangen....

Gruß
Michael