Audi Geschrieben 2. Juni 2010 Autor Teilen Geschrieben 2. Juni 2010 Ok, warst fleissig... ... Grüße Ripper Ok, warst fleissig.. Aber das war fast _zu_ ausführlich, aber nicht aussagekräftig genug Ich sehe wie deine Tabellen aufgebaut sind, weiss allerdings immer noch nicht, wie deine Ergebnismenge aussehen soll. (Was soll die Liste nachher liefern? Nicht die Spalten sondern der "Zweck" wäre interessant - Bsp: "Liste von Artikeln je Stückliste, gruppiert nach Stückliste") Ebensowenig weiß ich, was ARTLIEF, SARTIKEL und BESTDOK denn genau heissen soll!? SARTIKEL = Stücklistenartikel? BESTDOK = Lieferant nehm ich an? ARTLIEF = Artikelstamm?? Da würde mir spontan einfallen: WO steht die ID einer Stückliste? Natürlich kann ein Artikel von mehreren Lieferanten geliefert werden und wiederum in mehreren Stücklisten benutzt werden. Ich denke, deswegen hattest Du das DISTINCT benutzt. Aber das Ganze als Liste runterlaufen zu lassen ist ja an sich unsinnig..(nochmal: Zweck deiner Abfrage ist zumindest mir unklar) Grüße Ripper Du warst bis jetzt auch immer fleißig! :uli ARTLIEF = Artikel Lieferant, da steht z.B die Artikelnummer, Bestellnummer, Lieferantennummer, Mindestbestellmenge, Rabatt usw. drin. BESTDOK = Bestell Dokument, da sind Daten wie: Wann wurde bestellt (Datum), Lieferantname, Anschrift des Lieferanten, KunderNr., Ansprechparter usw. enthalten. SARTIKEL = Artikelstamm: Artikelnumemr, Name, Beschreibung, Mengeneinheit, Lagerort usw. Die ID der Einzelnen Tabellen ist schwierig zu sagen: In SARTIKEL habe ich als PK z.B Artikelnummer genommen, sonst kann ich keine PKs erstellen, da Redundanzen bestehen... In der Tabelle BESTDOK gibt es eine Spalte mit IDs, jeder Zeile ist eine bestimmte Ziffer zugeordnet. Ich gehe da bis jetzt nach der Lieferantennummer, da der Lieferantenname über die Lieferantennummer leicht herauszufinden ist. In der Tabelle ARTLIEF sind beide Spalten vorhanden, wie Artikelnummer, die auch in SARTIKEL vorhanden ist und Lieferantenummer, die ja in BESTDOK verfügbar ist. Deshalb habe ich auch über die Spalten alles miteinander Verknüpft. Die Ergebnissmenge soll natürlich alle Spalten die angesprochen wurden enthalten, sortiert nach Artikelnummer. Es muss jede Zeile eindeutig sein, also nicht doppelt vorhanden sein. Eine Zeile sieht dann so aus: Artikelnummer, Bauteilname, Bauteilparameter, Beschreibung, Bestelnummer (Hersteller), ArtikelInfo, EK-Preis, Bestnummer (Distributor), Distributor; Lagerort C00 000 014; TransistorXY; GrößeXY; DatenXY; ABC5202; Sanyo; 20,00€; 99100C; Reichelt Elektronik; R2-D2; Habe gestern noch die Indizierung versucht, aber es scheint dass schon alles Indiziert ist, so dass es nichts bringt. Wenn ich in der Tabelle in die Entwurfsansicht gehe, dort meine Spalte bzw. Spalten aussuche und dann auf diese Indizierungs-Symbol neben dem PK-Symbol klicke sind schon Indizes vorhanden... Den kleinen Performance anstieg habe ich wie schon erwähnt, durch Gruppierung nach "ErsterWert" vom Lieferanten bekommen. Und nochwas habe ich entdekt, erst wenn ich die Tabelle BESTDOK berücksichtige wird alles langsam Bestimmt ist da der Hund :old Als mir das Projekt zugeteilt wurde, gab es in einer generierten Access DB schon eine Abfrage um Artikellisten in Excel zu generieren. Diese habe ich auch in mein Programm eingebaut, aus dem Grund, weil ich auf ein Kaufmänische DB zugreife, diese ist Access kompatiebel, man kann auf diese DB aber nicht sichtbar zugreifen, deswegen benutze eine extra erstellte Benutzeroberfläche um die Daten sichbar zu machen die man zur Artikelsuche braucht. Das hat auch funktioniert nur eben langsam. Man will von mir jetzt dass das ganze schneller ist, sonst wird die eigentliche Hilfe zu einer sehr Zeitaufwendigen Sache. Kann dir die vorherige Abfrage mal posten, da ist noch eine Tabelle (ARTIKELMENGE) zwischen ARTLIEF und SARTIKEL, ka warum das der Ersteller gemacht hat? Diese Tabelle brauche ich nicht, deswegen wurde sie nicht berücksichtigt, die Geschwindigkeit hat sich nicht geändert... Ausgabe ist natürlich gleich! Zu dieser Abfrage ist noch eine von mir erstellte Suchabfrage dazugekommen, die wird jetzt nicht berücksichtigt, damit man nicht sagen kann, dass es an ihr liegt. Das ganze funktioniert, so dass ich nach beliebigen Begriffen/Teilbegriffen suchen kann. Wie gesagt wird jetzt nicht berücksichtigt, da es jetzt eh langsam ist und ich keine Performance steigerung merke, wenn ich die Suchabfrage noch dazu mache... Die DB wurde auch auf den Lokalen Rechner gezogen, hat aber 0,nix an Leistung gebracht! Also gibt es keine Engstelle, zwischen Server und Client Wenn du möchtest könnte ich die Tabellen so umbauen, dass ich dir die DB schicken könnte, dann hat man 100% Durchblick. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
RipperFox Geschrieben 2. Juni 2010 Teilen Geschrieben 2. Juni 2010 Tabelle BESTDOK: BestDocLiefNr (LieferantNr) BestDocName1 (Lieferantenname) vs. BESTDOK = Bestell Dokument, da sind Daten wie: Wann wurde bestellt (Datum), Lieferantname, Anschrift des Lieferanten, KunderNr., Ansprechparter usw. enthalten. Ja wie denn nu??? Und nochwas habe ich entdekt, erst wenn ich die Tabelle BESTDOK berücksichtige wird alles langsam Bestimmt ist da der Hund :old Jetzt wirds mir auch langsam klar Momentan wird wohl die Tabelle BESTDOK komplett dursucht werden um die BestDocLiefNr passend zu ArtLiefLiefNr zu finden. Indizes auf ARTLIEF.ArtLiefLiefNr und BESTDOK.BestDocLiefNr existieren? Ich denke deine Tabellen sind nicht ganz sauber normalisiert: Ihr bestellt sicher öfter bei einem Lieferanten - ergo sind "Lieferant" und "Lieferung" (BESTDOK) doch zu trennen, oder? Grüße Ripper Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 2. Juni 2010 Autor Teilen Geschrieben 2. Juni 2010 vs. Ja wie denn nu??? Jetzt wirds mir auch langsam klar Momentan wird wohl die Tabelle BESTDOK komplett dursucht werden um die BestDocLiefNr passend zu ArtLiefLiefNr zu finden. Indizes auf ARTLIEF.ArtLiefLiefNr und BESTDOK.BestDocLiefNr existieren? Ich denke deine Tabellen sind nicht ganz sauber normalisiert: Ihr bestellt sicher öfter bei einem Lieferanten - ergo sind "Lieferant" und "Lieferung" (BESTDOK) doch zu trennen, oder? Grüße Ripper Soll ich alle Spalten von den Tabellen aufschreiben??? Das sind aber in manchen über 30Stk... Habe nur wichtige herausgepickt... So siehts aus!:-) Deswegen auch so lahm Wäre schon ein großer Vorteil, wenn man direkt zeigt wo er genau suchen muss, mit Indizes funzt das auch bestimmt! Bekomme dass nicht hin, kann keine Indizierung auf andere Tabellen machen! Habe schon 2 Anleitungen durch, aber da gibts nichts zum auswählen in anderen Tabellen, nur in der man sich befindet, evt. kannst du was damit anfangen, wie bekomme ich andere Tabellen zur Auswahl? Sind schon fast am Zeil, oder Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
RipperFox Geschrieben 2. Juni 2010 Teilen Geschrieben 2. Juni 2010 Du braucht nur je einen Index in den Tabellen anzulegen, welcher eben die beschriebenen Spalten enthält - wo genau hängts? Grüße Ripper Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
_n4p_ Geschrieben 2. Juni 2010 Teilen Geschrieben 2. Juni 2010 aber da gibts nichts zum auswählen in anderen Tabellen, nur in der man sich befindet, evt. kannst du was damit anfangen, wie bekomme ich andere Tabellen zur Auswahl? zur frage, wahrscheinlich garnicht. warum willst du auch eine spalte aus eriner anderen tabelle auswählen? indizes sind tabellen bezogen, wenn du jetzt n index tab1.blah in tabelle tab2 erzeugst bringt das gar nichts weil das DBS ihn nicht findet. du musst jeden index in der tabelle anlegen in der sich auch die spalte befindet die du indizieren willst. und fremdschlüssel brauchst du hier eigentlich nicht, falls du daran gedacht hast. es reicht für die abfrage völlig indizierte spalten zu haben um den table scan zu vermeiden. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 2. Juni 2010 Autor Teilen Geschrieben 2. Juni 2010 Du braucht nur je einen Index in den Tabellen anzulegen, welcher eben die beschriebenen Spalten enthält - wo genau hängts? Grüße Ripper Am anlegen, kannst mal bitte kurz beschreiben wie du vorgehts und ich sag dir dann woran es hängt, oder woran es lag. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
_n4p_ Geschrieben 2. Juni 2010 Teilen Geschrieben 2. Juni 2010 hatten wir das nicht schon auf seite 1? Access 2002: 4.1.2.1 Beispiel 81: Ein Feld mit einem Index versehen is sogar ne animation dabei. du meintest ja das ginge nur bei einer tabelle weil in der anderen die werte nich eindeutig sind. in dem fall die option "ja (duplikate möglich" wählen. Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 2. Juni 2010 Autor Teilen Geschrieben 2. Juni 2010 hatten wir das nicht schon auf seite 1? Access 2002: 4.1.2.1 Beispiel 81: Ein Feld mit einem Index versehen is sogar ne animation dabei. du meintest ja das ginge nur bei einer tabelle weil in der anderen die werte nich eindeutig sind. in dem fall die option "ja (duplikate möglich" wählen. Ich habs! :upps Hat aber 0 geschwindigkeit gebracht Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 6. Juni 2010 Autor Teilen Geschrieben 6. Juni 2010 Du braucht nur je einen Index in den Tabellen anzulegen, welcher eben die beschriebenen Spalten enthält - wo genau hängts? Grüße Ripper Indizes sind angelegt, nur für die Spalten die gebraucht werden, soll ja so schneller gehen... es brachte bei mir aber 0,nix Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
dr.dimitri Geschrieben 7. Juni 2010 Teilen Geschrieben 7. Juni 2010 Wie sehen denn die Zeiten aus, wenn Du die Datenbank mal auf die lokale Platte kopierst und dort die Abfrage laufen lässt? Dim Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 9. Juni 2010 Autor Teilen Geschrieben 9. Juni 2010 Wie sehen denn die Zeiten aus, wenn Du die Datenbank mal auf die lokale Platte kopierst und dort die Abfrage laufen lässt? Dim wie schon gesagt, es ändert sich an der Performance nichts... Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 9. Juni 2010 Autor Teilen Geschrieben 9. Juni 2010 Ich mache das jetzt Programmiertechnisch, sollte dann um einiges schneller, bzw. blitzschnell gehen Wollte schon gerne wissen, wie man diese verflixte Abfrage schneller hinbekommt, aber was soll man machen...will ja nicht die ganze DB umbauen... Habe es mir so vorgestellt, dass ich die Abfrage von Access beim Programmstart aufrufe, dann werden die Ergebnisse der Abfrage in einer DataTable im RAM gespeichert, in dieser wird dann gesucht und die Suchergebnisse in einer weiteren DataTable ausgegeben, diese liefert die Ergebnisse an eine DataGridView die es dem Benutzer visuel ermöglicht die Artikel zu betrachten und weitere gewünschte Schritte zu unternehmen. Fange am Freitag an, mal schauen, wie lange ich brauch Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 9. Juni 2010 Teilen Geschrieben 9. Juni 2010 Ich mache das jetzt Programmiertechnisch, sollte dann um einiges schneller, bzw. blitzschnell gehen Wollte schon gerne wissen, wie man diese verflixte Abfrage schneller hinbekommt, aber was soll man machen...will ja nicht die ganze DB umbauen... Ich denke nicht, dass es das auf Dauer sein wird, denn ein DBMS Server ist meist leistungsfähiger als ein Client. Access ist für "kleine" Projekte durchaus zu verwenden, für größere sollte man aber eben z.B. auf ein MS SQL umsteigen, wobei man eine Access Datenbank direkt dort importieren kann (andere Alternativen wie mySQL, Postgresql, .... gibt es natürlich auch) Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Audi Geschrieben 11. Juni 2010 Autor Teilen Geschrieben 11. Juni 2010 Ich denke nicht, dass es das auf Dauer sein wird, denn ein DBMS Server ist meist leistungsfähiger als ein Client. Access ist für "kleine" Projekte durchaus zu verwenden, für größere sollte man aber eben z.B. auf ein MS SQL umsteigen, wobei man eine Access Datenbank direkt dort importieren kann (andere Alternativen wie mySQL, Postgresql, .... gibt es natürlich auch) Habs schon fertig War einfacher als gedacht, hatte als erstes auch vorgeschlagen es so zu machen, aber da gabs Leute die meinten, es sollte auch SQL mässig zu schaffen sein, nur hat sich unteranderem auch keiner Gedanken über die Kostennutzungsrechnung gemacht. Auf jeden Fall würde es mir und allen anderen viel Zeit und Nerven erspart, wenn es gleich Programmtechnisch gelöst worden wäre. Großes Dankeschön allen die sich für mich eingesetzt haben und mir helfen wollten! Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
flashpixx Geschrieben 11. Juni 2010 Teilen Geschrieben 11. Juni 2010 War einfacher als gedacht, hatte als erstes auch vorgeschlagen es so zu machen, aber da gabs Leute die meinten, es sollte auch SQL mässig zu schaffen sein, nur hat sich unteranderem auch keiner Gedanken über die Kostennutzungsrechnung gemacht. Ich hoffe, dass das dann auf Dauer kein Flaschenhals im System ist, der sich bei größerer Datenmenge doch noch nachteilig auswirkt. Aber ich gebe Dir recht, man muss eben bei leistungsfähigeren Lösungen auch die Kosten mit beachten, wobei man natürlich überlegen soll, ob die jetzige Lösung nicht nur ein Heftpflaster ist und man in einiger Zeit dann doch umstellen muss, wobei dann Deine Arbeit sprichwörtlich umsonst gewesen wäre Frohes schaffen Zitieren Link zu diesem Kommentar Auf anderen Seiten teilen Mehr Optionen zum Teilen...
Empfohlene Beiträge
Dein Kommentar
Du kannst jetzt schreiben und Dich später registrieren. Wenn Du ein Konto hast, melde Dich jetzt an, um unter Deinem Benutzernamen zu schreiben.