starten sie kostenlos
Visual Studio Developer Center >
> 
> 
alternative zu copy to

Frage alternative zu copy to

  • Freitag, 7. Januar 2011 10:56
     
     
    Anmelden
    0
    Moin, moin.
     
    Wir haben hier ein kleines Performance Problem.
    Wenn eine Tabelle sehr viele Datensätze hat (2-3mio, größe der DBF hinterher ist ca. 1GB), und man möchte die per
    copy to dbf database test
     
    kopieren, dann dauert das ziemlich lange.
     
    Konkret rufe ich Daten per Select vom SQL Server ab und möchte diese Daten in einer FoxPro DBF (mit dbc ...) ablegen (wird dann gezippt und per email an eine Filiale gesendet die die Daten importiert...)
     
    Hat jemand ne Idee, was ich alternativ zum copy to einsetzen könnte?
     
    Grüße
    Jörg Schneider
     
    Jörg Schneider
     

Alle Antworten

  • Freitag, 7. Januar 2011 11:58
     
     
    Anmelden
    0

    Moinsen Jörg,

    Also: Der SQL-Select legt ja schon mal nen Cursor (= temporäre DBF) LOKAL an, da haste deinen ersten COPY Vorgang. Wenn ich dich recht verstehe, dann kopiert du dann aus diesem SQL-Ergebnis wiederum in deine Ausgabedatei.

    Da der SQLEXEC() nicht direkt in ne Datei ausgeben kann, könntest du eventuell dich direkt auf die Ergebnisdatei aufschalten mittels DBF("AliasDerAbfrage").

    Aber prinzipiell muss man halt auch realisieren, dass es ganz einfach technische Limitierungen gibt. Das Übertragen und Umkopieren von 1 GigaByte an Daten dauert halt nun mal. Netzwerkgeschwindigkeit und PlattenController sind da eher der limitierende Faktor, nicht der VFP-Copy.

    Als Alternative könntest du natürlich die Daten auch direkt auf dem Server ausgeben, der SQL-Server hat da ebenfalls ein paar Methoden eingebaut, die du zB per StoredProcedure aufrufen kannst. Aber auch dann musste das Ergebnis weiterkopieren...

     

    wOOdy
    Microsoft Visual FoxPro Technology Advisor
    Microsoft "Most Valuable Professional" from 1996 to 2009
    Visit my XING profile!

    *´¨)
    ¸.·´¸.·*´¨) ¸.·*¨)
    (¸.·´. (¸.·` *
    .·`.Visual FoxPro: It's magic !
    (¸.·``··*


     

     
  • Donnerstag, 13. Januar 2011 08:56
     
     
    Anmelden
    0
    Moin!
     
    Danke für Deine Aw.
     
    Ja kopieren tu ich schon teilweise mit dbf("AliasSQLCursor").
     
    Aber FoxPro ist beim Copy To trotzdem langsam. Z.B.: Das Stonefield Database Toolkit macht anstelle eines PAC ein copy to. Wenn Du da ne große Dbf/fpt hast (so ab 600MB) dann geht die copy to Performance richtig heftig in die Knie. Also Lokal meine ich. Im Netz sind mir die Limitierungen klar.
     
    Na ja, hatte gehofft jemand hat nen Trick auf lager, so wie dbf() mit nem Cursor...
     
    Grüße
    Jörg
     
    Am 07.01.2011 12:58, schrieb Jürgen Wondzinski:
    > Moinsen Jörg,
    >
    > Also: Der SQL-Select legt ja schon mal nen Cursor (= temporäre DBF) LOKAL an, da haste deinen ersten COPY Vorgang. Wenn ich dich recht verstehe, dann kopiert du dann aus diesem SQL-Ergebnis wiederum in deine Ausgabedatei.
    >
    > Da der SQLEXEC() nicht direkt in ne Datei ausgeben kann, könntest du eventuell dich direkt auf die Ergebnisdatei aufschalten mittels DBF("AliasDerAbfrage").
    >
    > Aber prinzipiell muss man halt auch realisieren, dass es ganz einfach technische Limitierungen gibt. Das Übertragen und Umkopieren von 1 GigaByte an Daten dauert halt nun mal. Netzwerkgeschwindigkeit und PlattenController sind da eher der limitierende Faktor, nicht der VFP-Copy.
    >
    > Als Alternative könntest du natürlich die Daten auch direkt auf dem Server ausgeben, der SQL-Server hat da ebenfalls ein paar Methoden eingebaut, die du zB per StoredProcedure aufrufen kannst. Aber auch dann musste das Ergebnis weiterkopieren...
    >
    > ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    ---
    >
    > wOOdy
    > Microsoft Visual FoxPro <http://msdn.com/vfoxpro> Technology Advisor
    > Microsoft "Most Valuable Professional <http://mvp.support.microsoft.com/>" from 1996 to 2009
    >
    > *´¨)
    > ¸.·´¸.·*´¨) ¸.·*¨)
    > (¸.·´. (¸.·` *
    > .·`.Visual FoxPro: It's magic !
    > (¸.·``··*
    >
    >
     
     
    Jörg Schneider
     
  • Donnerstag, 13. Januar 2011 10:08
     
     
    Anmelden
    0

    Hi Jörg,

    zuerst noch ne kurze Housekeeping-Rule: Bitte nicht die komplette Bezugs-Nachricht wiederholen, das bläht den Verlauf nur unnötig auf, und verwirrt extrem. Bitte editier den Rest aus deiner Nachricht raus.

    ansonsten noch: Hast du zufällig nen Index aktiviert? Nur ohne Index kann der COPY TO sequentiell die Daten wegschreiben. Genauso kann ein "WITH CDX" bzw "WITH PRODUCTION" die Performance in den Keller gehen lassen.  Besser ist es, die Indizes erst nach dem COPY auf der Zieltabelle neu zu erstellen.

     

    wOOdy
    Microsoft Visual FoxPro Technology Advisor
    Microsoft "Most Valuable Professional" from 1996 to 2009
    Visit my XING profile!

    *´¨)
    ¸.·´¸.·*´¨) ¸.·*¨)
    (¸.·´. (¸.·` *
    .·`.Visual FoxPro: It's magic !
    (¸.·``··*


     

     
  • Sonntag, 23. Januar 2011 10:44
     
     
    Anmelden
    0

    >Z.B.: Das Stonefield Database Toolkit macht anstelle eines PAC ein copy to. Wenn Du da
    >ne große Dbf/fpt hast (so ab 600MB) dann geht die copy to Performance richtig heftig in die Knie.

    Kann ich nicht bestätigen, 600MB kopieren dauert halt. Aber auch nur linear mehr Zeit gegenüber kleineren Tabellen.

    Das einzige ist, daß bei SET DELETED ON sowohl bei SQL also auch bei allen Befehlen, die eine FOR-Klausel unterstützen implizit auf DELETED() = .F. gefiltert wird. Da Dein SQL Cursor garantiert weder gelöschte Datensätze noch einen Index auf Deleted() hat, kann also SET DELETED OFF den Kopiervorgang etwas beschleunigen. Aber auch wiederum nur linear zur Datenmenge, es gibt keinen Turbo a la Datei verschieben statt kopieren.

    Stonefield, wenn es das als Ersatz für COPY TO macht (glaube ich Dir) macht das sicherlich bei SET DELETED ON. Und anschließend generert es die Indizes aus seinen Metadaten über die Datenbank/Tabelle.

    Was wOOdy sagt ist natürlich ebenso richtig: COPY TO WITH CDX/PRODCUTION baut den Index beim kopieren neu auf, weil die Daten ja über den Filter (auch wenn keiner angegeben wird) Datensatzweise kopiert werden und so auch Datensatzweise der CDX neu aufgebaut wird, was in einem Rutsch per anschließender Indexierung schneller geht.

    Aber so wie Du keine gelöschten Sätze in einem SQL Server Result hast, hast Du auch keinen Index, insofern ist das wohl kaum zu befürchten.

    Probiere mal SET DELETED OFF vor COPY TO, aber verspreche Dir keinen Turbo. Du kannst auch nochmal prüfen wie lange eigentlich die Abfrage dauert und wie lange das COPY TO. Wenn Du asynchrone connection zum SQL Server nimmst, stell das bloß auf synchron um. Du kannst dann ja mal per TOP Klause verschiedene Mengen durchprobieren, das muß linear mit der Menge länger dauern, es gibt keinen Faktor der die Dauer anders als linear anwachsen ließe. Kopiervorgänge dauern nun einmal linear mit der Dateigröße.

    Tschüß, Olaf.