|
Member
Beiträge: 16
| Moin
es gibt ja auch viele Gründe, warum Daten sortiert vorliegen sollen 
In diesem Fall soll jede PZN um Eigenschaften ergänzt werden. diese sind wiederum Standabhängig. Alle 2 Wochen gibt es einen neuen Stand der PZN-Definitionen in einer eigenen Tabelle. Diese führe ich in einer Tabelle zusammen, aber nur dann, wenn sich für eine PZN Änderungen ergeben. Um diese der Tabelle Daten zuzuordnen, muss also das Datum und auch der Geltungsstand der PZN berücksichtigt werden. Dazu habe ich mir folgendes Schema ausgedacht mit dem Hintergedanken, beide recht lange Tabellen jeweils mit dem schnellsten Cursor nur einmal durchlaufen zu müssen. Und das ist auch bei großen Tabellen tatsächlich zackig abgearbeitet:
d.Open "daten", CurrentProject.Connection, adOpenForwardOnly, adLockPessimistic '
s.Open "stamm_pzn", CurrentProject.Connection, adOpenForwardOnly, adLockReadOnly '
d.MoveFirst: s.MoveFirst
Do
Select Case True
Case d!pzn < s!pzn
s.MoveNext
If s.EOF = True Then Exit Do
Case d!pzn > s!pzn
d.MoveNext
If d.EOF = True Then Exit Do
Case Else
If d![vo-datum] >= s!stand Then
d!ATC = s!ATC
d!DDD = s!DDD
d!Biosim = s!Biosim
d!BTM = s!BTM
d.MoveNext
If d.EOF = True Then Exit Do
Else
s.MoveNext
If s.EOF = True Then Exit Do
End If
End Select
Loop
Ich arbeite aus mehreren Gründen hier ohne Indizierung.
Und ich wählte die SQL-Variante SELECT INTO, weil ich damit in der Lage bin, bei umfangreichen Datenbeständen unterbrechen und nach dem Sortieren komprimieren zu können.
Ein Datensatz hat etwa 150 Zeichen.
Ich kann danach ja auch erkennen, dass sortiert wurde, zumindest am Anfang der Tabelle. Aber irgendwo mittendrin ist die Sortierung halt manchmal unterbrochen. Und dann scheitert natürlich der obige Algorithmus.
Die Tabelle Daten wird am Ende auch auf den SQL-Server exportiert und in eine große Tabelle gepackt, anhand der die Endauswertung erfolgt. Es gibt meist viele Wege, die nach Rom führen. Sicher könnte ich auch komplett auf dem SQL-Server arbeiten. Allerdings ist unser Intranet weder schnell noch stabil, so dass ich so viel wie möglich lokal abarbeite. Eigene Tests haben gezeigt, dass lokal mit Access arbeiten, bei limitierten Datenmengen natürlich, schneller ist, wenngleich nicht viel, als mit dem SQL-Server.
Ich vermute das Problem auch eher an anderer Stelle als bei Access.
Gruß
| |
|
Probleme beim Erstellen von umsortierten Tabellen