Results 1 to 5 of 5

Thread: Datapomp Access naar MSSQL

  1. #1
    Senior Member
    Join Date
    Aug 2004
    Location
    Rotterdam
    Posts
    136

    Datapomp Access naar MSSQL

    Ik vraag mij af wat er efficiŽnter is om te doen.

    Kan ik beter elke Access record vertalen naar een INSERT INTO Query?
    Of een DataSet koppelen aan de MSSQL Tabel, Append en dan veld voor veld de waardes kopiŽren en een Post op de DataSet?

    Heeft iemand dit al eens bij de hand gehad?

  2. #2
    Ik vermoed dat de eerste optie sneller is omdat het minder overhead heeft en ook beter kan omgaan met grote hoeveelheden records. Maar... waarom test je het niet gewoon?

  3. #3
    Senior Member
    Join Date
    Aug 2004
    Location
    Rotterdam
    Posts
    136
    Quote Originally Posted by luigi View Post
    Ik vermoed dat de eerste optie sneller is omdat het minder overhead heeft en ook beter kan omgaan met grote hoeveelheden records. Maar... waarom test je het niet gewoon?
    Luiheid natuurlijk waarom iets testen dat een ander zo uit de mouw schudt omdat het al eens getest is.

    Maar ik zal de resultaten hier posten.

  4. #4
    Senior Member
    Join Date
    Aug 2004
    Location
    Rotterdam
    Posts
    136
    Na een weekeindje programmeren zijn hier de resultaten.

    Even wat info.

    Het programma moet log-gegevens uit een lokale Access DB uploaden naar een SQL Server.
    De Access DB wordt gevuld met log-gegevens van een machineproces.
    De lokale opslag wordt gebruikt omdat de machines standaard niet in een netwerkomgeving staan, of omdat er geen centrale SQL Server is.
    En het beperkt het installeren van de onze software tot het kopiŽren van de executable + een paar .accdb's.

    Elke keer dat er een compleet log is gecreŽerd moet dit naar de SQL Server worden gekopieerd.
    Voor die paar keer per dag is snelheid geen issue, maar er zijn ook machines die al sinds 2000 hun gegevens lokaal opslaan.
    Deze gegevens moeten eerst ook in de SQL Server terechtkomen. En dan is snelheid wel een dingetje.

    Even een plaatje van de tabellen structuur.
    Click image for larger version. 

Name:	Relations.png 
Views:	21 
Size:	7.1 KB 
ID:	8202
    Alle tabellen heb ca. 40 velden.
    Per Master, zijn er gemiddeld 2 Childs, per Child ca 35 ChildSubMany's.

    Bij deze test DB gaat het om ca 100000 records.

    Ik heb 3 dingen getest.
    1. Elk record SQLTbl.Append + Access.FieldCount x (SQLFld = AccesFld) + SQLTbl.Post.
    2. Elk record het Access record vertalen naar Values string, en met een "INSERT INTO Tbl (Columns) VALUES (Values)" in de SQL server schieten.
    3. Optie 2 maar nu worden voor Child en ChildSubMany alle records in ťťn grote Values string gestopt.

    NB. De Columns string voor de SQL insert wordt voor elke tabel maar 1x gecreŽerd per programma start. Dus die gooit geen roet in het eten.

    1. 300 Rec/Sec
    2. 200 Rec/Sec
    3. 750 Rec/sec

    Optie 1 is puur per record gezien de snelste.
    Optie 3 wint het echter door de ChildSubMany tabel. Door hiervan alle records in ťťn grote Values string te zetten krijg je een redelijke snelheidswinst.
    Bij machines waar er per Child dus nog meer ChildSubMany's zijn zal de winst nog groter worden.

    Er is nog meer snelheidswinst te behalen voor alle drie de opties door de FieldByName aanroepen te elimineren.
    FieldByName wordt gebruikt ivm verschil in veld namen tussen Access (met spaties) en SQL Server(kort en zonder spaties).
    Maar dat zal op alle opties hetzelfde effect hebben, waardoor de verhoudingen niet zullen veranderen.

  5. #5
    Senior Member
    Join Date
    Mar 2002
    Location
    Edam
    Posts
    408
    Je zou het via DML arrays kunnen proberen in firedac dat zou onbehoorlijk snel gaan ( https://docwiki.embarcadero.com/RADS...mand_(FireDAC) )

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •