| Autor |
Nachricht |
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
03. Feb 2010, 15:03
Rufname:
|
|
| Version: Office XP (2002) |
|
Hallo zusammen,
ich hab ein massives Problem:
ich hab eine Datenbank mit rund 2500 Datensätzen, die verschiedene Infos in insgesamt 15 Tabellen verteilt haben. Das ganze wird mit verschiedenen Userforms dargestellt und auch mit Berichten zum drucken gebracht. Nun wird alles immer langsamer... ich habe eine Userform die ich vor 15 Minuten angeklickt habe, aber sie ist immer noch nicht geöffnet. 
Verschiedene Dinge, die ich gefunden habe, hab ich schon ausprobiert:
DB in Frontend und Backend geteilt -> keine Verbesserung
Extras-Optionen-Allgemein-Informationen aufzeichen deaktiviert -> keine Verbesserung
bei den Tabelleneigenschaften den Unterdatenblattname auf [keines] gestellt -> keine Verbesserung
Die Datei mal lokal gespeichert und nur ich drauf Zugriff, auch keine Änderung...
Hier mal der SQL String, der derzeit seit mittlerweile schon 20 Minuten läuft:
| Code: |
SelectString = "SELECT History!Vorgang as Vorgang, SNrTyp!ID as SID, SNrTyp!Typ as SNrGr, Anlagendaten!SNr as SNr, Anlagendaten!Beschreibung as Beschreibung, WP!Tätigkeit as Tätigkeit, Adressverwaltung!Anrede as Anrede, Adressverwaltung!Name as Name, Adressverwaltung!Vorname as Vorname, Adressverwaltung!Firma as Firma, Adressverwaltung!ID as AdressID, WPAnsprechpartner!WPID as WPAnsprechWPID, WPAnsprechpartner!Ansprechpartner1 as Ansprech1, Anlagendaten!ID as AID, Zuordnung!ID as ZID, Zuordnung!AnlagenID as ZAID, WP!ZuordnungID as WPZID, Zuordnung!SNrTypID as ZSTypID, History!WPID as HWPID, History!Abgeschlossen as Abgeschlossen, WP!ID as WPID, WP!Nächster_Termin as Termin"
FromString = " FROM SNrTyp, Anlagendaten, WP, History, Zuordnung, Adressverwaltung, WPAnsprechpartner"
WhereString = " WHERE Anlagendaten!ID LIKE Zuordnung!AnlagenID AND WP!ZuordnungID LIKE Zuordnung!ID AND WP!ID LIKE History!WPID AND WPAnsprechpartner!WPID LIKE WP!ID AND WPAnsprechpartner!Ansprechpartner1 LIKE Adressverwaltung!ID AND History!Abgeschlossen=FALSE AND SNrTyp!ID LIKE Zuordnung!SNrTypID AND WP!Aktiv=TRUE"
OrderString = " ORDER BY YEAR(Nächster_Termin), MONTH(Nächster_Termin), DAY(Nächster_Termin), SNrTyp!Typ DESC, Anlagendaten!SNr" |
Ich hab das in die verschiedenen Strings geteilt, damit ich mehr "Übersicht" habe (soweit man da noch von wirklicher Übersicht sprechen kann).
liegts einfach an Access? Würde ich was gewinnen, wenn ich auf einen SQL Server mit einen Access Frontend wechseln würde?
Gruß DCX
Edit: das Ganze hat schonmal in ca. 1 bis 2 Minuten funktioniert, aber da waren die Tabellen mit weniger Daten. Vorallem die WP und History Tabelle sind nun mit ca. 500 Datensätzen gefüttert. Als es noch schneller war, dann waren es nur ca. 10% dieser Daten.
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
Gast
Verfasst am:
03. Feb 2010, 22:22
Rufname:
|
| |
| Version: Office XP (2002) |
|
| Zitat: | | liegts einfach an Access? |
Vermutlich eher an unzureichender Datenmodellierung und fehlender Indexierung.
Die sieben Tabellen im FROM-Teil erzeugen vor Auswertung der WHERE-Klausel einen CROSS JOIN (jeder Datensatz einer Tabelle wird mit jedem Datensatz der anderen Tabellen kombiniert):
500 DS * 500 DS * 30 DS * 5 DS * 75 DS * 15 DS * 7 DS ergeben rund 295 Mrd. DS. Das will durchgeackert werden, und da kommt selbst eine kräftige Maschine über Gebühr ins Schwitzen. Einige gescheite Maßnahmen im Vorfeld können Enormes bewirken.
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
04. Feb 2010, 13:56
Rufname:
|
|
| Version: Office XP (2002) |
|
Hallo,
genau so ist es - und deswegen gibt es in relationalen Datenbanken die JOINs.
Prinzipiell müßte es für Deinen SELECT in etwa so funktionieren:
| Code: | SELECT History.Vorgang AS Vorgang, SNrTyp.ID AS SID, SNrTyp.Typ AS SNrGr,
Anlagendaten.SNr AS SNr, Anlagendaten.Beschreibung AS Beschreibung,
WP.Tätigkeit AS Tätigkeit, Adressverwaltung.Anrede AS Anrede, Adressverwaltung.Name AS Name,
Adressverwaltung.Vorname AS Vorname, Adressverwaltung.Firma AS Firma,
Adressverwaltung.ID AS AdressID, WPAnsprechpartner.WPID AS WPAnsprechWPID,
WPAnsprechpartner.Ansprechpartner1 AS Ansprech1, Anlagendaten.ID AS AID,
Zuordnung.ID AS ZID, Zuordnung.AnlagenID AS ZAID, WP.ZuordnungID AS WPZID,
Zuordnung.SNrTypID AS ZSTypID, History.WPID AS HWPID, History.Abgeschlossen AS Abgeschlossen,
WP.ID AS WPID, WP.Nächster_Termin AS Termin
FROM WP LEFT JOIN Zuordnung ON WP.ZuordnungID = Zuordnung.ID
LEFT JOIN SNrTyp ON SNrTyp.ID = Zuordnung.SNrTypID
LEFT JOIN History ON WP.ID = History.WPID
LEFT JOIN WPAnsprechpartner ON WPAnsprechpartner.WPID = WP.ID
LEFT JOIN Adressverwaltung ON WPAnsprechpartner.Ansprechpartner1 = Adressverwaltung.ID
LEFT JOIN Anlagendaten ON Anlagendaten.ID = Zuordnung.AnlagenID
WHERE History.Abgeschlossen = FALSE
AND WP.Aktiv = TRUE
ORDER BY YEAR(Nächster_Termin),
MONTH(Nächster_Termin),
DAY(Nächster_Termin),
SNrTyp.Typ DESC,
Anlagendaten.SNr |
Wobei Access (leider) eine etwas eigenwillige Klammersyntax hat und es deswegen mit Copy/Paste wohl wahrscheinlich so nicht funktioniert. Aber das Prinzip kannst Du aus dem Code entnehmen: Du mußt einfach das Quellfeld im Query Designer auf das Zielfeld ziehen (also zum Beispiel "ZuordnungID" aus der Tabelle "WP" auf die Zieltabelle "Zuordnung" auf das dortige Feld "ID" und entsprechend mit allen anderen Verbindungen), um die Syntax kümmert sich Access dann selbst. Mit einem Doppelklick auf die Verbindungslinie kannst Du dann noch den Verbindungstyp bestimmen, das hängt von Deinen Anforderungen ab. Sicher ist immer "LEFT JOIN", weil dann im Fall, daß in der Zieltabelle eine ID nicht existiert, ein leerer Datensatz zurückgegeben wird. Bei so vielen Verknüpfungen wird Dir bei einem INNER JOIN (der Standardfall) nämlich nur dann eine Zeile zurückgegeben, wenn in ALLEN beteiligten Tabellen, die einen INNER JOIN verwenden, die jeweiligen IDs auf beiden Seiten der Verknüpfung existieren.
Gruß
Christian
|
|
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
05. Feb 2010, 09:15
Rufname:
|
|
| Version: Office XP (2002) |
|
Danke erstmal für den Lösungsansatz. Ich hatte mal SQL Abfragen in den Grundlagen gelernt, den JOIN Befehl kannte ich nicht bzw. hab ich wieder vergessen. Ist nun auch schon wieder ein paar Jahre her.
Was für mich nun noch klingt, wie spanische Dörfer ist dieser Query-Designer. Mit dem hab ich noch nie gearbeitet. Ich hab mir bis jetzt jegliche SQL Abfrage im Kopf ausgedacht und so auch programmiert - wie gesagt, bis jetzt funktionierte es ja eigentlich ganz gut.
Ich werd am Montag (wenn ich wieder auf der Arbeit bin und die Datenbank vor mir habe) mich mal näher mit dem Thema beschäftigen und dann hoffentlich ein Performancegewinn hinbekommen. Denn die Historytabelle ist die Tabelle, die ständig wachsen wird und mit ihren aktuellen rund 500 Einträgen gerade mal einen Bruchteil der zu erwartenden Datenmenge enthält. Hierbei geht es nämlich um eine Tabelle, die Wartungen und Prüfungen an Maschinen und Anlagen bei uns im Bereich über min. 10 Jahre dokumentiert (wegen Auditierung usw.). Der derzeitige Datenbestand sind die Wartungen und Prüfungen von 2 Monaten... sprich es fehlen noch 10 Monate und dann weiter 9 Jahre.
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
05. Feb 2010, 10:20
Rufname:
|
| |
| Version: Office XP (2002) |
|
Hallo,
dann frage ich mich, wie Du je ohne JOIN ausgekommen bist, denn das ist die Grundlage beinahe jeder relationalen Abfrage zwischen mehreren Tabellen...
Das Thema solltest Du Dir aber dringend anschauen, ansonsten wird das nix mit der Datenbank.
Du kannst SQL-Befehle natürlich auch von Hand schreiben - aber wozu? Der Query Designer von Access ist nicht schlecht und da Access so eine verkorkste SQL Syntax hat, ist er eine sehr gute Hilfe. Und es spart insbesondere bei solchen Monsterkonstrukten eine Menge Schreibarbeit.
Du solltest Deine Tabellen aber auch noch daraufhin überprüfen, wie sie genau zusammenhängen und welche Daten Du wirklich brauchst. In den seltensten Fällen sind solche Konstrukte wirklich notwendig und sinnvoll. Ich garantiere Dir, wenn Du die JOINs richtig gesetzt hast, liegen die Abfragezeiten auch bei zehntausenden Datensätzen maximal im Sekundenbereich.
Gruß
Christian
PS.: Und wenn Du dazu auch noch die Indizes richtig gesetzt hast, geht es gleich nochmal so gut...
|
|
Gast
Verfasst am:
05. Feb 2010, 11:15
Rufname:
|
|
| Version: Office XP (2002) |
|
Hilfsmittel:
- Literatur: Performance in Abfragen von Jürgen Zimmermann (hilft auch bei handerzeugtem Code)
- Abfrageanalyse: ShowplanCapturer von Sascha Trowitzsch
Nebenbei: Warum wird beim Sortieren das Datum geteilt? Die Sortierung nach dem Datumsfeld bringt den gleichen Effekt, verzichtet aber auf Anwendung unnötiger Funktionen (deren Ausführung auch Zeit benötigt - in der Masse spürbar).
In der WHERE-Klausel verhindert die Verwendung von Berechnungen auf das Tabellenfeld die Nutzung eines Index, in der ORDER BY-Klausel könnte das ähnlich sein.
| Code: | ...
ORDER BY WP.Nächster_Termin,
SNrTyp.Typ DESC,
Anlagendaten.SNr |
|
|
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
05. Feb 2010, 16:08
Rufname:
|
|
| Version: Office XP (2002) |
|
@Bitsqueezer:
Gut, wenn das zu den Grundlagen gehört, dann hab ich es wohl wieder verdrängt! ;) Ich hab das ca. 2002 gelernt und dieses Wissen nun erst wieder die letzten beiden Jahre gebraucht. Bisher kam ich immer ohne Join sehr gut zurecht. Die Performance war kein Problem... Nun haben wir die Datenbank etwas aufgeblasen und schon steh ich vor meinem Performanceproblem.
@Gast:
Meine Versuche das Datum in der von mir gewünschten Reihenfolge zu sortieren brachte nur mit diesem Ausdruck den Erfolg. Ich wollte es eben so, dass immer das älteste Datum oben steht. Es geht hier nämlich um fällige Termine, die dann - sollten sie "überfällig" (sagt man das so? *rätsel*) sein auch zwingend oben stehen müssen, damit man eben auf einer ToDo Liste sieht, was getan werden muss.
Danke aber mal für die Links, ich werd mich mal damit beschäftigen und hoffentlich auch ein bischen weiter kommen.
Gruß DCX
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
Gast
Verfasst am:
05. Feb 2010, 16:43
Rufname:
|
|
| Version: Office XP (2002) |
|
| Ein Datum (Datentyp Date) ist intern eine Zahl, und Zahlen lassen sich sehr gut sortieren.
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
05. Feb 2010, 21:06
Rufname:
|
|
| Version: Office XP (2002) |
|
Hallo DCX,
naja...bei einer Datenbank mit 2500 Datensätzen verteilt auf 15 Tabellen...das ist ja nicht gerade eine riesige Datenmenge und könnte in ähnlichem Tempo schon von Excel verarbeitet werden... 
Ohne Joins kann man nicht vernünftig mit Tabellenbeziehungen arbeiten, da hast Du Dich vermutlich nie richtig mit der Materie auseinandergesetzt. Wenn Du einmal gesehen hast, WIE schnell eine Datenbank wird, wenn sie vernünftig verknüpft und indiziert wird, wirst Du Dich fragen, wie Du je ohne ausgekommen bist.
Solange Du nur einzelne Tabellen und Tabellen mit 10-100 Datensätzen abfragst, brauchst Du Dir um Performance keine großen Gedanken zu machen.
Übrigens solltest Du beim Verknüpfen von IDs grundsätzlich kein "LIKE" verwenden, sondern immer "=". LIKE ist ein toller Operator, wenn es um das Auffinden von Teilstrings in Texten geht usw., aber für exakte Zahlendaten nimmt man immer "=", denn Du verknüpfst ja eine ID, die ist in der Regel eindeutig, daher gibt es keine Verwechslungsmöglichkeiten. Und schneller ist es auch.
Gruß
Christian
|
|
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
08. Feb 2010, 10:32
Rufname:
|
|
| Version: Office XP (2002) |
|
Hallo Christian,
ich sitz hier nun vor meiner Datenbank und blicks einfach nicht!
ich hab aus diesem SQL String
| Code: |
SQLString = "SELECT History!Vorgang as Vorgang, SNrTyp!ID as SID, SNrTyp!Typ as SNrGr, Anlagendaten!SNr as SNr, Anlagendaten!Beschreibung as Beschreibung, WP!Tätigkeit as Tätigkeit, Adressverwaltung!Anrede as Anrede, Adressverwaltung!Name as Name, Adressverwaltung!Vorname as Vorname, Adressverwaltung!Firma as Firma, Adressverwaltung!ID as AdressID, WPAnsprechpartner!WPID as WPAnsprechWPID, WPAnsprechpartner!Ansprechpartner1 as Ansprech1, Anlagendaten!ID as AID, Zuordnung!ID as ZID, Zuordnung!AnlagenID as ZAID, WP!ZuordnungID as WPZID, Zuordnung!SNrTypID as ZSTypID, History!WPID as HWPID, History!Abgeschlossen as Abgeschlossen, WP!ID as WPID, WP!Nächster_Termin as Termin " & _
"FROM SNrTyp, Anlagendaten, WP, History, Zuordnung, Adressverwaltung, WPAnsprechpartner " & _
"WHERE Anlagendaten!ID LIKE Zuordnung!AnlagenID AND WP!ZuordnungID LIKE Zuordnung!ID AND WP!ID LIKE History!WPID AND WPAnsprechpartner!WPID LIKE WP!ID AND WPAnsprechpartner!Ansprechpartner1 LIKE Adressverwaltung!ID AND History!Abgeschlossen=FALSE AND SNrTyp!ID LIKE Zuordnung!SNrTypID AND WP!Aktiv=TRUE AND WP!Nächster_Termin <= DATEVALUE('" & VarDatumBis & "') " & _
"ORDER BY YEAR(Nächster_Termin), MONTH(Nächster_Termin), DAY(Nächster_Termin), SNrTyp!Typ DESC, Anlagendaten!SNr" |
mit Hilfe des Abfragegenerators diesen SQLString gebastelt:
| Code: |
SQLString = "SELECT History.Vorgang, SNrTyp.ID, SNrTyp.Typ, Anlagendaten.SNr, Anlagendaten.Beschreibung, WP.Tätigkeit, Adressverwaltung.Anrede, Adressverwaltung.Name, Adressverwaltung.Vorname, Adressverwaltung.Firma, Adressverwaltung.ID, WPAnsprechpartner.WPID, WPAnsprechpartner.Ansprechpartner1, Anlagendaten.ID, Zuordnung.ID, Zuordnung.AnlagenID, WP.ZuordnungID, Zuordnung.SNrTypID, History.WPID, History.Abgeschlossen, WP.ID, WP.Nächster_Termin, WP.Aktiv " & _
"FROM (((((SNrTyp LEFT JOIN Anlagendaten ON SNrTyp.ID = Anlagendaten.ID) LEFT JOIN WP ON SNrTyp.ID = WP.ID) LEFT JOIN History ON WP.ID = History.WPID) LEFT JOIN Zuordnung ON (Anlagendaten.ID = Zuordnung.AnlagenID) AND (SNrTyp.ID = Zuordnung.SNrTypID)) LEFT JOIN Adressverwaltung ON SNrTyp.ID = Adressverwaltung.ID) LEFT JOIN WPAnsprechpartner ON SNrTyp.ID = WPAnsprechpartner.ID " & _
"WHERE ((SNrTyp!ID = Zuordnung!SNrTypID) And (WPAnsprechpartner!Ansprechpartner1 = Adressverwaltung!ID) And (WP!ZuordnungID = Zuordnung!ID) And (History!Abgeschlossen = False) And (WP!ID = History!WPID = WPAnsprechpartner!WPID) And (WP!Nächster_Termin <= DateValue('" & VarDatumBis & "')) And (Anlagendaten.ID = Zuordnung.AnlagenID) And (WP.Aktiv = True)) " & _
"ORDER BY YEAR(Nächster_Termin), MONTH(Nächster_Termin), DAY(Nächster_Termin), SNrTyp!Typ DESC, Anlagendaten!SNr" |
leider führt das zu keinem Treffer!
Als Anmerkung: Ich hab noch aus allen INNER JOINS des Ausdruckgenerators hab ich LEFT JOINs gemacht.
Ich versteh den JOIN Ausdruck in den Tutorials, die ich finde noch soweit, wenn ich 2 Tabellen verbinden will. Dieses Wissen aber auf meine 7 Tabellen zu übertragen schaff ich einfach nicht!
Ich dachte der Ausdrucksgenerator würde mir die Grundlagen liefern, so dass ich diesen Ausdruck noch ein bischen anpassen kann. Leider ist dem nicht so...
Gruß DCX
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
Bitsqueezer
Office-VBA-Programmierer
Verfasst am:
08. Feb 2010, 20:13
Rufname:
|
|
| Version: Office XP (2002) |
|
Hallo,
die Probleme liegen oft nicht in den Daten, sondern in der Struktur der Daten.
Im Prinzip funktioniert es (vereinfacht gesagt) so, daß Du Dir erst die Tabelle aussuchst, die die Basis für die Informationen liefert, die Du wissen möchtest. Also etwa aus einer Lagertabelle alle Einträge, unabhängig von dem, was da sonst noch kommt.
In der Lagertabelle steht dann vielleicht eine Produktnummer, die in einer Produkttabelle steht, jedes Produkt in der Produkttabelle hat eine eindeutige Produktnummer, und in der Lagertabelle ist diese für jeden Lagereintrag hinterlegt. Wenn es so eine 1:1-Beziehung gibt, kannst Du einen INNER JOIN verwenden, denn dann ist garantiert, daß es einen Eintrag für jede Produktnummer in der Produkttabelle gibt.
Der Stolperstein hierbei liegt aber darin, daß ein Eintrag in der Produkttabelle durchaus gelöscht worden sein kann, aber im Lager liegt immer noch so ein Teil und hat immer noch die gelöschte Produktnummer. Wenn man jetzt einen INNER JOIN macht, dann heißt das "zeige mir den Inhalt aus beiden Tabellen, wenn die Produktnummer in beiden Tabellen existiert". Wenn auch nur eine der beiden Tabellen keinen passenden Eintrag hat, wird die Zeile nicht gelistet.
Hier kommt der LEFT JOIN in's Spiel: Wenn die Tabelle Lager in jedem Fall gelistet werden soll, egal ob es in der Produkttabelle einen Eintrag gibt oder nicht, dann fügt man zunächst die Lagertabelle in den Abfrageeditor und als zweites die Produkttabelle. Dann zieht man wieder die Verbindung zwischen beiden, die automatisch einen INNER JOIN erzeugt. Dann klickt man mit der rechten Maustaste auf die Verbindungslinie und läßt sich die Eigenschaften der Verbindung anzeigen. Hier steht dann auch genau das (als eine mögliche Auswahl) im Klartext: "Zeige alle Datensätze der Tabelle Lager und nur die aus der Produkttabelle, bei der es eine Übereinstimmung gibt". Diese Option wählt man nun aus und dann werden in allen Fällen, in denen es keine Übereinstimmung gibt, für die Produkttabelle NULL-Werte angezeigt.
Mit mehreren Tabellen funktioniert es im Prinzip genauso. Auch hier muß man sich nur genau überlegen, welche der Tabellen die unbedingt wichtigen Informationen enthält und welche nur zum Nachsehen weiterer Informationen (wie oben die Produkttabelle, die mir z.B. den Produktnamen liefert) dient.
Dabei sollte man am besten immer eine Richtung beibehalten, immer LEFT JOIN oder immer RIGHT JOIN, je nach Verbindungsrichtung, obwohl auch gemixte Methoden möglich sind, aber für den Anfang wäre das sehr verwirrend und ist auch fehleranfällig.
Wenn die Produkttabelle also zum Beispiel eine ID enthält, die auf einen Produktstatus aus einer anderen Tabelle verweist, wäre der nächste LEFT JOIN dann von der Produkttabelle zur Produktstatustabelle zu ziehen usw. Am besten macht man nach dem Hinzufügen jeder neuen Tabelle immer erst eine Ausführung der Abfrage, um zu sehen, ob noch alles stimmt. Die Anzahl Datensätze muß nachher wie vorher immer gleich sein, denn ansonsten hat man irgendwo doppelte Einträge erzeugt.
Gruß
Christian
|
|
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
09. Feb 2010, 08:41
Rufname:
|
|
| Version: Office XP (2002) |
|
Soweit kann ich dir noch folgen.
Wo ich ins stolpern gerate ist bei den mehreren Tabellen, die nicht durch einen eindeutigen Schlüssel verbunden sind. In meinem Fall wäre es, dass folgende Tabellen zusammen hängen:
"Zuordnung" ist die Tabelle, die alles zusammen führt. Dort stehen nur Zahlen drin. So weißt diese Tabelle Detailinfos der Tabelle "Anlagendaten" zu. Nämlich bezogen auf das oben genannte Beispiel einen Nummerngruppe (zwei Buchstaben) aus der Tabelle "SNrTyp". Neben dieser Tabelle "SNrTyp" gibt es noch die Tabellen "Kst" (Kostenstelle), "Maschinentyp" (eine Kategorisierung welche Art von Maschine bzw. Anlage es ist). Dann gibt es wiederrum die Dateien WP und History, die Anhand der ID der Tabelle WP. Die letzte Gruppe sind die beiden Tabellen "Adressverwaltung" und "WPAnsprechpartner". In der Adressverwaltung stehen nur Adressen drin. In der Tabelle "WPAnsprechpartner" ist es wiederrum so, dass der ID der Tabelle WP ein oder zwei IDs der Adressverwaltung zugeordnet sind (also gibt es dort die Spalten Ansprechpartner1 und Ansprechpartner2 in der jeweils eine ID aus "Adressverwaltung" drinne steht). Also sind eigentlich die beiden führenden Tabellen "Zuordnung" und "WP" die beide über das Feld ID der Tabelle Zuordnung verknüpft sind.
So, versteht man nun, wie alles zusammen hängt? Mit welcher Tabelle würde ich nun Anfangen bei einem JOIN-Befehl? Mit der Zuordnung?
Was ich auch noch nicht so richtig verstanden habe:
in vielen Beispielen ist es so, dass sobald der JOIN Befehl ins Spiel kommt, die SELECT Anweisung kürzer wird. Oder hab ich das nur falsch verstanden? Kann das sein?
Gruß DCX
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
DCX
Im Profil kannst Du frei den Rang ändern
Verfasst am:
09. Feb 2010, 14:06
Rufname:
|
| |
| Version: Office XP (2002) |
|
JUHU!!!
Ich habs geschafft!! Ich kapiere es zwar immer noch nicht, aber ich hab nun einfach meine Abfragen mit dem Abfrageassitenten zusammengeklickt, den SQL Code eingefügt und aus einer Abfrage die ich nach über 30 Minuten gekillt habe ist eine Abfrage von ein paar Millisekunden geworden!!!!
Vielen Dank für die Hilfe!!
_________________
Es gibt 10 Arten von Menschen - die, die das Binärsystem verstehen und die Anderen! ;)
|
|
Du kannst Beiträge in dieses Forum schreiben.
Du kannst auf Beiträge in diesem Forum antworten.
Du kannst deine Beiträge in diesem Forum nicht bearbeiten.
Du kannst deine Beiträge in diesem Forum nicht löschen.
Du kannst an Umfragen in diesem Forum nicht mitmachen.
Du kannst Dateien in diesem Forum nicht posten
Du kannst Dateien in diesem Forum herunterladen
|
| |
|
|
| Verwandte Themen |
| Forum / Themen |
Antworten |
Autor |
Aufrufe |
Letzter Beitrag |
 |
Access Berichte: Berichteditieren nur sehr langsam |
5 |
Freestila |
105 |
18. Jan 2010, 22:29
MissPh!  |
|
Access Tabellen & Abfragen: RecordSource Abfrage sehr langsam ... |
7 |
Wenn_Google_nicht_hilft |
109 |
13. Nov 2009, 15:19
Wenn_Google_nicht_hilft |
|
Access Programmierung / VBA: Access steuert Excel =langsam?->XMLExcel/XML Kalkulations |
1 |
Gast |
106 |
03. Nov 2009, 12:50
Gast |
|
Access Hilfe: Access zugriff auf Server extrem langsam |
2 |
Miranda |
404 |
05. Mai 2009, 12:50
Miranda |
|
Access Formulare: Total unter Subform funktioniert nicht |
5 |
galaxy |
84 |
04. März 2009, 02:02
Willi Wipp |
|
Access Programmierung / VBA: Access steuert Excel = langsam? |
7 |
chris_ |
571 |
26. Jan 2009, 19:50
Gast |
|
Access Programmierung / VBA: INSERT über VBA und DAO ewig langsam |
3 |
SimFirehawk |
1105 |
08. Dez 2008, 17:11
Willi Wipp |
|
Access Programmierung / VBA: Datenbank extrem langsam |
1 |
Gast |
426 |
09. Jul 2008, 10:50
klaus31 |
|
Access Formulare: Pivot ist extrem langsam |
0 |
friedet |
180 |
11. Jun 2008, 06:51
friedet |
|
Access Hilfe: Access in der Entwurfsansicht sehr langsam |
6 |
Job100 |
514 |
04. Jun 2008, 13:41
Job100 |
|
Access Formulare: Access MDE Formular langsam |
7 |
ccrueller |
2558 |
12. Jun 2007, 07:22
Lothar_OMC |
|
Access Hilfe: Komprimierung viel zu langsam |
0 |
wolfi86 |
292 |
03. Apr 2007, 06:55
wolfi86 |
| |
|
