nicht angemeldet
VBScript: Recordset zeilenweise kopieren
hallo,
kurze Frage:
wie kann ich einen kompletten Satz eines Recordsets kopieren?
rs.AddNew
rs(0) = rs2(0)
rs(1) = rs2(1)
... das will ich wir sparen
oder noch besser wäre
rs += rs2
oder
rs += rs.GetRows()
wenn sowas in der Art möglich ist geht?
Hintergrund: "rs" ist ein internes Recordset an das ich mehrere "rs2" anfügen will, um alle Daten nachher in einem Recordset verarbeiten zu können (sortieren, ausgeben, etc.).
Wenn einer ne Idee hat - vielen Dank schon mal
Gruss,
Seppel
-
wie kann ich einen kompletten Satz eines Recordsets kopieren?
Ich habe lange nicht mehr mit dem recordset-Objekt gearbeitet, aber
- es gibt Navigationsmethoden (MoveNext, MoveLast etc.)
- es gibt Kopiermethoden (Klonen)
- es gibt Suchmethoden
Hintergrund: "rs" ist ein internes Recordset an das ich mehrere "rs2" anfügen will, um alle Daten nachher in einem Recordset verarbeiten zu können (sortieren, ausgeben, etc.).
Man fügt an einen recordset keinen recordset an.
Wenn einer ne Idee hat - vielen Dank schon mal
Ich würde Dir gerne helfen, aber bitte überdenke noch einmal Deine Fragestellung unter der Fragestellung "Was ist ein recordset?".
-
Hi,
Ich habe lange nicht mehr mit dem recordset-Objekt gearbeitet, aber
- es gibt Navigationsmethoden (MoveNext, MoveLast etc.)
- es gibt Kopiermethoden (Klonen)
- es gibt Suchmethoden
kenn ich und benutz ich auch wo sie gebraucht werden - nur für diesen Zweck nicht...das Klonen hilft nicht, da die Sätze, die bereits im rs sind, auch bleiben sollen.
Man fügt an einen recordset keinen recordset an.
Joa, würd ich dir recht geben - meinerseits vielleicht blöd vormuliert - ich will ja nur die Sätze des 2. Recordsets denen des 1. hinzufügen.
Ich würde Dir gerne helfen, aber bitte überdenke noch einmal Deine Fragestellung unter der Fragestellung "Was ist ein recordset?".
Fragestellung so klarer? Ist ja eigentlich auch kein wesentliches Problem die "Spalten" in meinen Recordsets einzeln zu übertragen - nur unschön.
Danke und Gruss,
Seppel-
Ich würde Dir gerne helfen, aber bitte überdenke noch einmal Deine Fragestellung unter der Fragestellung "Was ist ein recordset?".
Fragestellung so klarer? Ist ja eigentlich auch kein wesentliches Problem die "Spalten" in meinen Recordsets einzeln zu übertragen - nur unschön.
Leider nicht, was heisst denn nun "VBScript: Recordset zeilenweise kopieren" genau? Willst Du vertikal filtern? Oder horizontal (vgl. "Spalten")?
-
Ich kann dem Hamster nur beipflichten: seppel, bitte beschreibe mal ohne Bezug auf die Verwendung von Recordsets, was du erreichen möchtest.
Evt. lässt sich eine Lösung finden, die nicht erst Recordsets (mit Client-seitigen oder Server-seitigen Cursors) abzurufen braucht.
Cheers,
Frank-
Ich kann dem Hamster nur beipflichten: seppel, bitte beschreibe mal ohne Bezug auf die Verwendung von Recordsets, was du erreichen möchtest.
wie im letzten Beitrag beschrieben - möchte ich unterteilte SQL-Results in einem "Objekt" zusammenführen um sie nachher komplett verarbeiten und übergeben zu können.
Gruss,
Seppel-
wie im letzten Beitrag beschrieben - möchte ich unterteilte SQL-Results in einem "Objekt" zusammenführen um sie nachher komplett verarbeiten und übergeben zu können.
Es gibt doch die Add()-Methode, oder?
-
Es gibt doch die Add()-Methode, oder?
mit der Add Methode fügt man aber leider nur eine Zeile hinzu...so mache ich es ja derzeit.
Deswegen ja meine Frage - gibt es eine Möglichkeit gleich das komplette neue RS dem bestehenden hinzuzufügen?
-
-
Hallihallo,
unsere letzten beiden Beiträge waren annähernd zeitgleich.
Grundsätzlich: Deinen angeführten Performancegrund gegen ein Union halte ich für unnötig konstruiert. Will heissen, du machst einen Denkfehler.
Daten, die du sowieso zusammen verarbeiten willst in mehreren Teilen (Aufrufen) zu holen (was bedeutet zusätzliches Marshaling, Interprozess-Kommunikation usw) und dann im Arbeitsspeicher zusammenzufügen wirkt sich noch negativer auf die Performance aus, das 2. Original Recordset bleibt ja erstmal erhalten und das 1. wird um das 2. noch vergrössert.Aus deinen Beiträgen entnehme ich: Ein Union ist technisch gesehen möglich, die Daten haben auch dieselbe Struktur und sie stammen wohl aus der selben Quelle (Datenbank).
2. Thema: Wohin und warum willst du die zusammengeführten Daten übergeben?
3. Das Adodb.Recordset bietet keinen Bulkload. Du kannst aber
- das 1. Recordset in einen Xml-Stream serialisieren (.Save Methode)
- das 2. Recordset in einem 2. Xml-Stream serialisieren
- beide Xml-Streams mithilfe von XMLDOM/XSL zusammenführen
- das Resultat wieder als Recordset laden (.Open / ADODB.Stream usw.)
Aber effektiver (performanter) als
a) eine Schleife und .AddNew oder
b) eine Union Abfrage
wirst du nicht sein.Wie mein Kollege immer so gern sagt: Back to field 1 / Gehen Sie zurück auf "Start", ziehen Sie nicht DM 4000 ein.
Mit anderen Worten, überdenke bitte dein Vorhaben nochmal von Anfang an. Es gibt ganz sicher einen besseren Weg.
Ciao, Frank
-
Nabend,
erstmal danke, dass du dir die Zeit nochmals genommen hast dich mit meinem "Problem" zu befassen!
Grundsätzlich: Deinen angeführten Performancegrund gegen ein Union halte ich für unnötig konstruiert. Will heissen, du machst einen Denkfehler.
Korrigier mich bitte wenn ich mit folgender Annahme falsch liege: Ich dachte nur, dass mein Code beim Zusammenführen mehrerer Ergebnisse schneller ist, als die Datenbank mit einem SQL-Statement zu quälen, welches bis zu 1000 Unions umfassen würde...geschweigedenn alle Suchkriterien (in meinem Fall Kunden-Nummern) in eine "in(1,2,3,...,n)-Bedingung" zu packen.
Bevor du jetzt (zu Recht) anmerkst, dass ich mir doch dann lieber Gedanken über eine Gruppen-Nummer o.ä. machen sollte...das hab ich mir dann nämlich auch überlegt und werde es wahrscheinlich so lösen.
Daten, die du sowieso zusammen verarbeiten willst in mehreren Teilen (Aufrufen) zu holen (was bedeutet zusätzliches Marshaling, Interprozess-Kommunikation usw) und dann im Arbeitsspeicher zusammenzufügen wirkt sich noch negativer auf die Performance aus, das 2. Original Recordset bleibt ja erstmal erhalten und das 1. wird um das 2. noch vergrössert.
Najo, das 2. wird ja innerhalb der Schleife jedes Mal geschlossen und mit einer anderen Query wieder zum fetchen der neuen Sätze benutzt.
Aus deinen Beiträgen entnehme ich: Ein Union ist technisch gesehen möglich, die Daten haben auch dieselbe Struktur und sie stammen wohl aus der selben Quelle (Datenbank).
Jo ;)
- Thema: Wohin und warum willst du die zusammengeführten Daten übergeben?
die behalte ich im Arbeitsspeicher, damit ich nicht jedes mal neu abfragen muss...sonst springen mir die DB-Leute aufn Kopf. Ich kann mir schon denken das es da bestimmt bessere/sauberere Möglichkeiten gibt (Trigger, o.ä.) aber 1. läuft es so gut und 2. kann ich das nicht ;)
Aber effektiver (performanter) als
a) eine Schleife und .AddNew oder
b) eine Union Abfrage
wirst du nicht sein.Kannst du mir sagen (ernst gemeinte Frage) was es für die Datenbank bedeutet, einen Union über x Abfragen zu machen...führt er das intern einzeln aus und fügt es nur für die Ausgabe zusammen oder ist es, wie ich gedacht hatte, ein Mehraufwand im Gegensatz zu einzelnen Abfragen?
Mit anderen Worten, überdenke bitte dein Vorhaben nochmal von Anfang an. Es gibt ganz sicher einen besseren Weg.
Auch damit könntest du Recht haben, ich denke mit der Einführung der Gruppen-Nr und einem entsprechenden Index werde ich die Rückgabe der Daten auch in einer Query performant machen können.
Fassen wir zusammen, für jene die ggf. doch an dem Thema: Recordset zeilenweise kopieren interessiert waren und deshalb den Thread gelesen haben: es scheint also keinen anderen Weg ausser (wie von Frank beschrieben) den über das XML-Gefuckel zu geben, um einen Recordset einem anderen "anzuhängen".
Trotzdem vielen Dank und schönen Abend noch
Seppel-
Korrigier mich bitte wenn ich mit folgender Annahme falsch liege: Ich dachte nur, dass mein Code beim Zusammenführen mehrerer Ergebnisse schneller ist, als die Datenbank mit einem SQL-Statement zu quälen, welches bis zu 1000 Unions umfassen würde...geschweigedenn alle Suchkriterien (in meinem Fall Kunden-Nummern) in eine "in(1,2,3,...,n)-Bedingung" zu packen.
Da liegst Du falsch, besser als 1.000 UNIONs allerdings die Menge mit IN.
-
Da liegst Du falsch, besser als 1.000 UNIONs allerdings die Menge mit IN.
Also falsch liege ich mit dem Code - OK. Aber den 2. Teil deiner Aussage versteh ich nicht...aber ich glaub trotzdem das ich weiss was gemeint sein könnte:
Union ist bestimmt besser als IN (da IN quasi ne OR-Abfrage ist...)
ergo - ich nehm Union statt Code-mässiges Basteln.
Danke
-
Da liegst Du falsch, besser als 1.000 UNIONs allerdings die Menge mit IN.
hab mir deinen Satz grad bei ner Kippe noch mal durchn Kopf gehen lassen: meinst du allen Ernstes:
"besser als 1.000 UNIONs " ist "allerdings die Menge mit IN"
Nie im Leben...
-
"besser als 1.000 UNIONs " ist "allerdings die Menge mit IN"
Nie im Leben...Dann stell Dir doch mal vor Du wärst der Datenbankserver, was wäre Dir lieber, ein SELECT mit grosser WHERE-Klausel oder ganz, ganz viele SELECTs per UNION verbunden?
-
Dann stell Dir doch mal vor Du wärst der Datenbankserver, was wäre Dir lieber, ein SELECT mit grosser WHERE-Klausel oder ganz, ganz viele SELECTs per UNION verbunden?
Bin kein Experte, aber ich denke das ist für den Datenbankserver ziehmlich egal, da er auch bei einer IN-Bedingung mit jedem einzelnen Element den, im besten Fall vorhanden, Index quälen muss.
Es gibt ja nur zwei Möglichkeiten wie er die Abfrage "where ID in (1, 2, 3)" ausführen könnte:
entweder er fragt "where ID=1 or ID=2 or ID=3", wobei er für jede Bedingung den Index befragt
oder er macht intern quasi Unions daraus und fragt ebenfalls einzeln ab...
Keine Ahnung, hab leider keinen passenden Beitrag im Netz gefunden (hab auch nicht lange gesucht), aber das wird wahrscheinlich relativ egal sein.
Wenn du was findest - gesetz dem Fall es interessiert dich überhaupt - kannst du ja mal posten was das DBMS (oder der was-weiß-ich-DB-Optimierer) daraus macht.
Gute Nacht,
Seppel
-
-
-
-
Hallo,
wir hatten bisher nur von "UNION" gesprochen, aber nicht von 1000.
Warum willst du 1000 UNION Abfragen machen? Warum reicht nicht eine?Und ein Abfrageoptimierer ist dankbar für einen Index ... bzw. das gesamte DBMS ist dankbar dafür wenn der Abfrageoptimierer einen nutzen kann, denn das bedeutet einen (meistens um einiges) geringeren Resourcenverbrauch.
Lass dir die Ausführungspläne für deine Abfragen anzeigen und analysiere sie, bzw. finde einen fähigen Datenbank-Menschen dafür.
So long,
Frank-
Moin,
wir hatten bisher nur von "UNION" gesprochen, aber nicht von 1000.
Warum willst du 1000 UNION Abfragen machen? Warum reicht nicht eine?mit 1000 Unions meinte ich EIN SQL-Statement mit 1000 Unions. d.h.
Select bla
union --1
select blabla
union --2
select blablabla
...
union --1000Und ein Abfrageoptimierer ist dankbar für einen Index ... bzw. das gesamte DBMS ist dankbar dafür wenn der Abfrageoptimierer einen nutzen kann, denn das bedeutet einen (meistens um einiges) geringeren Resourcenverbrauch.
schon klar, sonst müsste er ja alle Sätze sequentiell durchsuchen...
Lass dir die Ausführungspläne für deine Abfragen anzeigen und analysiere sie, bzw. finde einen fähigen Datenbank-Menschen dafür.
schon gemacht...und die Frage ob Union oder IN-Bedingung kann man pauschal nie beantworten - in meinem Fall (entsprechend dem Typ des angelegten/genutzten Indexes) soll ich IN nehmen bis die Gruppen-Nr steht.
Danke noch mal und schönen Tag noch.
-
-
-
-
-
Leider nicht, was heisst denn nun "VBScript: Recordset zeilenweise kopieren" genau? Willst Du vertikal filtern? Oder horizontal (vgl. "Spalten")?
Filtern will ich garnicht - also nicht zu dem Zeitpunkt. Ich habe einen Recordset der mit einem SQL-Result gefüttert ist:
...
rs.Open SQL, connectionund dann sollen weitere Sätze hinzugefügt werden:
...
rs2.Open SQL, connection"Kopier/Anfügevorgang" derzeit:
rs.AddNew
rs(0) = rs2(0)
rs(1) = rs2(1)
usw...den Inhalt des rs2 will ich also dem rs anfügen - so das der rs nachher beide Ergebnisse beinhaltet.
Warum ich nicht direkt einen Union beim SQL-Statement mache hat Performance-Gründe.
Danke für dein Nachfragen - wär cool hier eine Lösung zu finden.
Gruss,
Seppel
-