Hallo,
ich habe ziemliche Performance Probleme. Wenn ich durch mein Formular scrolle dauert es teilweise sehr lange bis die Felder die ihre Werte über DLookUp Funktionen, oder Berechnungen( =Wenn(...)) erhalten gefüllt sind.
Meine DB ist in ein FE und ein BE aufgeteilt, das BE liegt auf einem Server, das FE ist lokal bei mir auf dem Rechner.
Wie könnte man das ganze beschleunigen?
Gibt es eine Möglichkeit das ganze Formular einmal "berechnen" zu lassen, sodass nicht immer nur der Bereich der aktuell im Bild ist geladen wird und sobald man scrollt wieder geladen werden muss.
LG Kinimod
Hallo,
Zitatdie ihre Werte über DLookUp Funktionen, oder Berechnungen( =Wenn(...)) erhalten
DLookup und Wenn sind natürlich Performance Killer.
Warum verwendest Du kein gebundenen Formulare ?
Und wenn in einer Datenbank Wenn Funktionen erforderlich sind, so liegt meist ein ungeeignetes Datenmodell vor.
Zeige mal ein Bild des Beziehungsfensters.
Hallo,
in dem Fall, dass auch für Dlookup Schlüsselfelder zur Ermittlung der Werte herangezogen werden, wäre eine über die beteiligten Tabellen verknüpfende Abfrage für die Datenherkunft des vermutlich gebundenen Endlosforms einzusetzen.
Die DLookUp Funktion verwende ich, da die Daten in dem Formular bearbeitet werden können müssen. Dass habe ich anders nicht hin bekommen.
Die Wenn Funktion verwende ich in einem Konstrukt bei dem ich selbst weiß, dass das nicht optimal ist: Jeder Datensatz hat mehrere Felder mit Geldbeträgen und ein Feld (Währung) das die Währung angibt. Die Währung inerhalb eines Datensatzes ist gleich, unterschiedliche Datensätze können aber unterschiedliche Währungen haben (EUR, USD, GBP). Es soll nun hinter jeden Geldbetrag das passende Währungszeichen (€,$, £) angezeigt werden. Access zeigt aber beim Feldtyp Währung immer das im System eingestellte Währungszeichen, in meinem Fall €, an. Also hab ich mir damit beholfen, dass hinter jedem Feld mit einem Geldbetrag ein zusätzliches Feld mit meiner Wenn- Abfrage steht:
=Wenn([Währung]="EUR";"€";Wenn([Währung]="USD";"$";Wenn([Währung]="GBP";"£";"k.A.")))
In beiden Fällen ist mein Problem, dass ich es nicht anders hin bekomme, dass man die Daten in dem Formular weiterhin bearbeiten kann.
Angehängt noch ein Bild des Beziehungsfensters.
Hallo,
das Problem ist lösbar, wenn Du die Tabellen (bzw. Daten) nach u. st. Links 1, 1a und 1b analysierst und neu aufbaust.
Die derzeitigen wilden "Beziehungen" sind unbrauchbar, desgleichen der Tabellenaufbau.
Weiterhin sollten dringend Sonder- und Leerzeichen sowie reservierte Wörter vermieden werden.
ZitatDie Währung innerhalb eines Datensatzes ist gleich, unterschiedliche Datensätze können aber unterschiedliche Währungen haben (EUR, USD, GBP). Es soll nun hinter jeden Geldbetrag das passende Währungszeichen (€,$, £) angezeigt werden. Access zeigt aber beim Feldtyp Währung immer das im System eingestellte Währungszeichen, in meinem Fall €, an.
Um
nur diese Aufgabe zu lösen: Führe ein Feld "WährungID_f" (Zahl,Long) in der Tabelle mit und setze eine n:1-Beziehung auf Feld "WährungID" in "tblWährung" .
tblWährung:
WährungID (Autowert)
Kürzel (Text)
Zeichen (Text)
Order Liste DB (besser "tblOrders"):
"Währung" in " in "WährungID_f" (Zahl, Long) ändern
Im Formular wird ein Kombifeld an WährungID_f gebunden, die Daten für die Kombifeldliste werden aus tblWährung geholt:
Datensatzherkunft: Select WährungID, Kürzel from tblWährung order by Kürzel
Gebundene Spalte: 1
Spaltenbreiten: 0cm;2cm
Das Kombi kann neben jedem Geldbetrag kopiert (dupliziert) werden.
Dies ist nur eine Krücke für die aktuelle Situation. Das Ganze ist in einer korrekt aufgebauten (normalisierten) Tabellenstruktur überflüssig, bzw. kann auch ein (nötiges) Kombifeld reduziert werden.
ZitatAccess zeigt aber beim Feldtyp Währung immer das im System eingestellte Währungszeichen, in meinem Fall €, an.
Access zeigt das Währungszeichen (Euro) nur dann an, wenn in der Format-Eigenschaft für das Textfeld (in der Tabelle und/oder Formular) "Euro" steht. Lösch diesen Format-Eintrag.
Danke für deine Antwort. Ich hab mich jetzt an einem neuen Entwurf versucht, sieht es jetzt besser aus?
Ich hab den Entwurf nochmal angepasst und versucht eine Abfrage mit den benötigten Feldern zu erstellen. Das Problem ist das ich in dieser Abfrage (in der Datenblattansicht) wieder keine Daten ändern kann.
Hallo,
das dürfte nicht passen. Auch die Doppelbeziehungen dürften falsch sein.
Bitte erkläre mal den Zweck (bzw. die Aufgabe) der DB und die Bedeutung der Tabellen.
Es sollen Bestellungen verwaltet werden. Eine Bestellung kann mehrere Positionen haben und jede Position kann in mehreren Teilen abgerechnet werden.
tbl_Customer: Manche Kunden haben ein Siglum, das hier zugewiesen wird. Allerdings soll das Siglum händisch für einzelne Bestellungen änderbar sein und eine Änderung des Siglums in dieser Tabelle soll nicht in tbl_Orders übernohmen werden, daher ist es hier nochmal vorhanden. Daher hab ich momentan so eingerichtet, dass wenn das Feld Siglum in tbl_Orders leer ist der Wert aus tbl_Customer übernommen wird. Ich weiß, dass eigentlich keine redundanten Daten vorkommen sollen, aber das Siglum weicht manchmal von der tbl_Customer ab.
tbl_Profitcenter:Gleiches Thema wie mit dem Siglum Feld PC in tbl_Orders entspricht in den meisten Fällen dem Profitcenter aus tbl_Profitcenter, muss aber individuelle Abweichungen erlauben.
Hoffe man kann es verstehen.
Hallo,
es sieht zumin dest schon mal besser aus als vorher... 8)
Füge in tbl_Positionen einen Autowert-Feld als Primärschlüssel ein. Der wird mit einem Fremdschlüsselfeld in tbl_Abrechnungsmeld... (PO) in Bezihung gesetzt. Die Beziehung zwischen den "Position"-Feldern entfällt.
Welchen Zweck hat die Abfrage im Beziehungsfenster? Die solltest Du entfernen.
Ansonsten weise ich nochmal darauf hin, keine Sonder- und Leerzeichen in Namen zu verwenden.
ZitatFüge in tbl_Positionen einen Autowert-Feld als Primärschlüssel ein. Der wird mit einem Fremdschlüsselfeld in tbl_Abrechnungsmeld... (PO) in Bezihung gesetzt. Die Beziehung zwischen den "Position"-Feldern entfällt.
Das verstehe ich nicht:
Alle Positionen mit der gleichen PO gehören zu der gleichen Order daher ist tbl_Orders.PO in Beziehung mit tbl_Positionen.PO.
Alle Abrechnungsmeldungen mit der gleichen PO und der gleichen Position gehören zu der gleichen Position, der gleichen Order. Dann müsste dass mit der doppel Beziehung doch richtig sein, oder steh ich da auf dem Schlauch. Ich verstehe nicht, wie ich das über eine einfache Beziehung zwischen tbl_Positionen.Positions_ID und tbl_Abrechnungsmeldung.PO darstellen kann, außerdem ist es mir nicht möglich diese Bezeihung zu erstellen, da nicht der gleiche Feldwert (Autowert vs. kurzer Text) vorliegt.
Außerdem kann ich durch den neuen Primärschlüssel nun mehrmals die gleiche Position für eine Order haben. Irgendwie steige ich da noch nicht ganz durch :-\
Hallo,
Po und PositionsNr erhalten einen eindeutigen, zusammengesetzten Index. Dann sind keine doppelten Positionen möglich.
Die PosID (Primärschlüssel) kennzeichnet eindeutig eine bestimmte Position zu einer bestimmten Bestellung.
Somit kann zu diesem Primärschlüssel ein Fremdschlüsselfeld in Abrechnungen als 1:n-Beziehung gesetzt werden. Die (mehreren) Abrechnungen beziehen sich dann auf genau eine bestimmte Position in einer bestimmten Bestellung.
(In der Tat können zwei Index-Felder in zwei Beziehungen verwendet werden. Ein Primärschlüssel als Autowert vereinfacht aber die den Tabellenaufbau und die Datenbehandlung.
Zitataußerdem ist es mir nicht möglich diese Beziehung zu erstellen, da nicht der gleiche Feldwert (Autowert vs. kurzer Text) vorliegt.
Nun, da fällt mir als Lösung ein, den Datentyp anzupassen... :o Tabellenfelder für Beziehungen sollten immer den Datentyp Zahl, Long besitzen.
Ok, erstmal danke, den zusammengesetzten Index kannte ich noch nicht.
Ich häng mal meine aktuellen Beziehungen an.
Allerdings hänge ich jetzt bei einem wahrscheinlich sehr einfachen Problem:
Ich schaffe es nicht eine Abfrage zu erstellen die beispielsweise eine vernünftige Ansicht für Abrechnungsmeldungen erstellt in der ich auch neue Abrechnungsmeldungen erstellen kann. Nur die Ansicht ist kein Problem, die hänge ich mal an. Die Felder [PO][Pos] möchte ich nur zur Identifikation nutzen, da der Nutzer ja nicht den Schlüssel kennt, aber aktuell möchte er [PO][Pos] noch in die Tabelle tbl_Positionen schreiben. Allso im Grunde möchte ich [PO][Pos] angeben und daraus soll [PositionsID_f] werden.
Hallo,
eine "vernünftige" (so wie Du es meinst) Ansicht bekommst Du nicht mit Abfragen, für solche "Layouts" und Datenmanipulationen sind Formulare da..
Zitat
Die Felder [PO][Pos] möchte ich nur zur Identifikation nutzen, da der Nutzer ja nicht den Schlüssel kennt, aber aktuell möchte er [PO][Pos] noch in die Tabelle tbl_Positionen schreiben. Allso im Grunde möchte ich [PO][Pos] angeben und daraus soll [PositionsID_f] werden.
Falls ich es recht verstehe, soll beim Anlegen eines neuen DS in tbl_Abrechnungsmeldungen der Wert für das "PositionsID_f"-Feld generiert werden..
Das geschieht automatisch, wenn eine HFO/UFO/UFO-Konstruktion aufgebaut und die Eigenschaften richtig gesetzt werden:
Erstelle für alle Tabellen je ein Endlosform (Datenherkunft => Tabellenname) , außer für tbl_Orders , für die wird ein Einzelform ("Orders") verwendet.
In frmOrders werden für die Fremdschlüsselfelder gebundene Kombifelder eingesetzt, die ihre Daten für die Kombifeldliste aus den entspr. 1-Tabellen erhalten. Damit kann jeweils der gewünschte DS aus den Nachschlagetabellen ausgewählt und dessen Primärschlüsselwert in tbl_Orders abgelegt werden.
Weiterhin erhält frmOrders ein UFO-Steuerelement im Detailbereich , das Formular "frmPositionen" anzeigt und über die Schlüsselfelder verknüpft (Eigenschaften "Verknüpfen von /nach"). Das frmPositionen selber erhält ein UFO-Steuerelement, jetzt allerdings im Formularfuß, eingebaut, das das Formular "frmAbrechnungsmeldungen" anzeigt. Auch hier sind die Eigenschaften "Verknüpfen von/nach" auf die diesbezüglichen Schlüsselfelder zu setzen.
Wird jetzt in einer Order eine Position markiert (Datensatzmarkierer), so zeigt das Form im Formularfuß die zugehörigen Abrechnungen an. Alle Daten, bis auf die Autowerte und Fremdschlüssel, können editiert, hinzugefügt und gelöscht werden.
btw: Es gibt immer noch Sonderzeichen ("-") in Tabellenfeld-Namen...
Danke, werde es erst Freitag ausprobieren können und dann Rückmeldung geben :)
Ziel sind Formulare in Dattenblattansicht. Für Abrechnungsmeldung also etwa:
[PO][Position][Item_Description][Items_abgerechnet][...]
Hallo,
ZitatZiel sind Formulare in Dattenblattansicht.
nicht zu empfehlen. Nimm Endlosforms mit passendem Layout.
Was spricht gegen die Datenblattansicht? Bei einem Endlosformular stoße ich an die max. Formularbreite und generell finde ich es bis jetzt angenehmer in der Dattenblattansicht zu arbeiten, da man z.B. die Spalten selbst in der Breite und Höhe verändern kann.
Bei dem Formular hab ich noch meine Probleme, ich bin jetzt erstmal einen Schritt zurück geggangen und versuche die Funktion dahinter zu verstehen:
Ich versuche ein Formular frmOrders zu erstellen das alle Felder aus tblOrders enthält nur, dass statt Customer_ID der Wert Customer aus tblCustomer angezeigt wird. Mit einem Kombifeld habe ich das soweit auch hin bekommen, jedoch kann ich da keinen Namen eingeben, der noch nicht in tblCustomer vorhanden ist. Wie ist es möglich den neuen Namen aus frmOrders in einen neuen DS in tblCustomer zu übernehmen.
Mein Ziel Ist ein Formular, dass der angehängten Abfrage entspricht, nur, dass ich DS hinzufügen und manipulieren kann. Tabellarischer Aufbau, Daten aus mehreren Tabellen und berechnete Daten.
Ich glaube ich hab es jetzt ungefähr so wie du es vorgeschlagen hast. Allerdings weiß ich nicht wie ich jetzt die Währung in das Unterformular bekomme.
Hallo,
Zitatwie ich jetzt die Währung in das Unterformular bekomme.
In dem du die in die tblPositionen verlagerst, wo sie IMO auch hingehören.
gruss ekkehard