Office: (Office 2003) Tabellenerstellung aus Struktur per VBA

Hallo zusammen,
prinzipiell geht es mir um ein Performance-Problem.
Folgende Lösung funktioniert:
1. Lesen einer (beliebigen) SAP-Tabelle via RFC-Aufruf
2. Anlegen der ACCESS-Tabelle via TableDefs.append [Tabelle].
3. Kopieren des Tabelleninhalts aus der gelieferten Struktur der SAP-TableFactory in die ACCESS-Tabelle mittels addNew und füllen der einzelnen Felder.

Mein Problem: Das Ganze wird ab 20.000 Datensätzen ziemlich langsam.

Wesentlich schneller geht es, wenn man die Daten von einem Text-File importiert.
Ich habe folgende Optimierungsansätze:
1. Daten der SAP-TableFactory als Textdatei speichern und via Import in die frisch erzeugte Tabelle schreiben - kennt da jemand eine Lösung?
2. Kopieren einer ganzen Tabellen-Spalte (gibt es einen "move correponding"?) auf einmal - gibt es so was ?

Oder hat jemand eine andere Lösung parat wie man "schnell" Tabellen aus einer Datenstruktur füllt?

Vielen Dank für Eure Hilfe!

:)

 

Hallo,

mit der Transfertext-Methode kannst du eine Textdatei in eine vordefinierte Tabelle importieren. Beim manuellen Import-Verfahren kannst du die gewünschten Einstellungen als Importspezifikation speichern, welche du dann beim Ausführen per VBA einsetzen kannst.

Hoffe, das hilft weiter.

 

Hallo Anne,
den TransferText kenne ich, das Problem liegt in der Erstellung der Importquelle aus der Struktur.
Kennt jemand dazu eine performante Möglichkeit? Es geht hier um die SAP TableFactory.
Danke schon mal!
Thomas

 

Meinst du damit die Gesamtlaufzeit, oder wird die Anfügezeit je DS ab dem 20000. DS langsamer? (bis 19999. DS schnell, ab dann langsam?)

Du könntest einmal ein Insert über ein ADODB-Recordset mit UpdateBatch probieren.

Beispiel:
Code:

 

Hallo,
die Geschwindigkeit nimmt mit steigender Anzahl Datensätze ab - seltsamerweise auch, wenn ich die Key's der Tabelle erst im Anschluss an die Betankung setze.
@josef: Ich denke, da kommt es zu keinem wesentlichen Zeitvorteil. Die Zeitverschwendung passiert wahrscheinlich in den Schleifendurchläufen.
Hier kommt mal der relevante Code, der je zu kopierender Zeile aufgerufen wird:
Code:

Da ich meine Tabellen im Voraus nicht kenne, muss ich aber flexibel bleiben. Deswegen die Frage nach einem "Move Correponding" wie in Cobol.
Hast Du noch einen Tipp?
Thomas

 

Derzeit bestimmt, weil auch das Befüllen der Tabelle in der Schleife ist. *wink.gif*
Ich könnte mir schon vorstellen, dass ein UpdateBatch etwas bringt.
Probiere es einfach einmal aus, es ist ja nicht unbedingt viel Aufwand den Import auf UpdateBatch umzustellen, oder?

Da ich meine Tabellen im Voraus nicht kenne, muss ich aber flexibel bleiben. Deswegen die Frage nach einem "Move Correponding" wie in Cobol.

Ich kenne "Move Correponding" nicht, da ich Cobol noch nie verwendete. *wink.gif*
Wenn du mir beschreibst, was du damit erreichen willst, kann ich dir vielleicht eine Lösung unter VBA zeigen.


/Nachtrag:
Auch das exakte Ansprechen von Feldern kann einen kleinen Geschwindigkeitsvorteil bringen. (aber nur in einer Schleife, wenn die Felder mehrmals angesprochen werden.)

Prinzip (DAO):
Code:

 

\@Josef: Werde mal den UpdateBatch probieren.
"Move Corresponding" in Cobol kopiert in einer beliebigen Struktur nur die Felder gleichen Namens - alle auf einmal!

 

So etwas kenne ich unter VBA nicht, dafür müsstest du dir eine eigene Funktion schreiben.
Wobei mir aber das Anliegen etwas ungewöhnlich vorkommt. Wie willst du eine Tabelle weiterverwenden, wenn deren Felder nicht einmal bekannt sind? - Woher weißt du dann, welche Datentypen verwendet werden sollen?
Wenn die Import-Struktur unbekannt ist, wäre es dann nicht sinnvoller jedesmal eine neue Tabelle zu erstellen - ohne manuellen Eingriff wirst du doch kaum mit dieser Tabelle etwas machen können - denn fixe Abfragen kann es aufgrund mangelnder Kenntnis der Feldnamen nicht geben.

 

Hallo Josef,
die Routine dient dazu, beliebige Tabellen aus SAP herunterzuladen und damit dann im ACCESS weiterzuarbeiten - meistens manuell, Analyse und so.
Ich kenne selbstverständlich die Tabellen die heruntergeladen werden vorher, habe aber keine Lust, für jede Tabelle extra eine eigene Routine zu schreiben.

Es gibt aber auch Programme von mir, die täglich automatisch laufen und auch Tabellen aus SAP abrufen und da gibt es eben bei drei Tabellen Performance-Probleme mit der Kopiererei (2* ca. 70.000 Rows, 1* ca. 200.000 Rows -> Laufzeit > 10h, Tendenz steigend).

Was mich jetzt halt ziemlich verblüfft ist die Tatsache, dass ein Import der Tabellendaten (die drei Tabellen von oben) aus einer Textdatei nur ein paar Minuten dauert - und da möchte ich hin (es gibt da auch Tabellen mit >500.000 Rows und die brauche ich eben manchmal auch).

Entweder schaffe ich es, die Daten aus der SAP-TableFactory sehr performant in eine Datei zu schreiben und dann den importTable zu starten, oder ich muss meine Routine verbessern.

Ich habe Deinen Tip mit dem BatchUpdate anhand einer Tabelle mit 1300 Rows getestet:

• DAO: 6 sec

• ADO: 18 sec

Leider!

 

Ich probierte nun auch UpdateBatch aus und stellte fest, dass UpdateBatch um vieles langsamer als der direkte Import ist. => lieber bei DAO bleiben. *wink.gif*

Bezüglich deiner Idee mit dem Textexport:
Du könntest unter VBA mit der Print#-Anweisung eine Textdatei erstellen.
Teste aber vielleicht noch die Variante mit den deklarierten DAO-Feldern.
Möglicherweise hängt die Zeit gar nicht auf Access-Seite, sondern am Zugriff auf die SAP-Struktur.
Teste einfach einmal den Import-Vorgang mit einer Schleife ohne SAP-Referenzen.
Code:

Und als Vergleich vielleicht noch:
Code:

Wenn das auch so lange benötigt, dann liegt das Problem eindeutig beim DAO-Datenimport. Wenn nicht, wird vermutlich die Text-Export-Variante auch nicht besonders viel bringen, da die Zeit beim "Zusammenstellen" der Werte liegen bleibt.

Anm.: bei meinem Test benötigt die DAO-Import-Schleife 300 ms für 20k Datensätze.

 

\@Josef:
Auf die Idee den Bösewicht bei SAP zu suchen bin ich ja noch gar nicht gekommen *wink.gif*
Werde ich gleich mal ausprobieren - Ich fülle die Tabelle mal nur mit Konstanten. Dazu muss ich aber einen "select case" einbauen, der das Ergebnis etwas verfälschen könnte - mal sehen!
Danke für den Tip!
Thomas

 

Das muss auch nicht sein. Es könnte durchaus sein, dass deine Variante für denZugriff nicht besonders optimal ist. *wink.gif*
Aber bevor man nach Optimierungsmöglichkeiten sucht, sollte man erstmal herausfinden, wo es sich lohnt. ... eine Optimierung von 1 ms für 20k DS wird sich nicht besonders lohnen, wenn auf einer anderen Stelle vielleicht 10ms je DS möglich sind. *biggrin.gif*

 

Gebe ich Dir voll und ganz recht!

 

So, ich habe mal ein bisschen probiert:
Füllen der Tabelle ohne Zugriff auf die SAP-Struktur verringert die Füllzeit bei ca 1400 rows von 6sec auf 1sec - ordentlich (aber leider halt nicht tauglich).
Daraufhin habe ich die Datenzuweisung geändert auf:
Code:

Ich verzichte also auf die Überprüfung des Spaltennamens und gehe davon aus, dass beide Strukturen von wegen der Positionierung der Felder identisch sind (stimmt immer dann, wenn ich die Tabelle vorher auch angelegt habe)
Dann ergibt sich eine Verbesserung von 6sec auf 4sec.
Getestet bei 5800 Rows: von 25sec auf 17sec.
Ergibt eine Verbesserung ca. 30%.

Erst einmal nicht schlecht, aber vielleicht hat ja jemand noch eine weitere Idee.

Viele Grüße
Thomas

 

Als 2. Variante könntest du testen, wie der Zugriff auf die SAP-Objekte ohne Recordset-Befüllung läuft. (also nur die Werte in eine Variable lesen)


BTW: Ich erwähnte es zwar bereits 2x wiederhole es aber gerne noch einmal, da du damit möglicherweise auch die Probleme mit der Feldauswahl in den Griff bekommst.

Prinzip:
Code:

Eine weitere Variante wäre das Fixieren der Feldnamen im DAO-Recordset (also nur die gemeinamen Felder ins Rs aufnehmen). Damit könntest du dort nur per Index zugreifen - was fast so schnell wie das direkte Ansprechen der Felder per DAO.field ist.