/ Forside / Teknologi / Udvikling / VB/Basic / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
VB/Basic
#NavnPoint
berpox 2425
pete 1435
CADmageren 1251
gibson 1230
Phylock 887
gandalf 836
AntonV 790
strarup 750
Benjamin... 700
10  tom.kise 610
Midlertidlig lagring af ADO-Recordset
Fra : Jesper Stocholm


Dato : 22-03-03 11:24

Jeg har lavet en lille hjælpe-app, der loader en SQL-fil og sender
indholdet af den imod en databaseserver (TeraData). En del af kravene til
applikationen er, at den skal kunne gemme resultatet af en forespørgsel
(der altid er et recordset) i en fil på disk.

Når jeg har siddet og tænkt lidt over, hvordan det skal skrues sammen, så
vil jeg mene, at det giver mest mening af spørger brugeren om denne vil
gemme resultatet _efter_ forespørgslen er blevet af viklet.

Altså et flow som dette:

Klik knap "Run query"
If (Result = OK)
Enable button "Store result"

If (button is clicked)
Use CmdDialog to navigate to and create a file
end if
       
Mit problem er nu - hvordan lagrer jeg resultatet imellem de to
handlinger ? Skal jeg gemme resultatet i \temp og hvis det ønskes gemt -
så kopiere filen fra \temp til den rigtige lokation ? Resultatet af
forespørgslen er typisk på flere hundrede tusinde rækker, så det skal
helst håndteres så optimalt som muligt. Hvis resultatet ikke skal gemmes
er jeg ikke glad for at skulle håndtere dette i hukommelsen, og det bør
vel helst fjernes fra applikationen i det øjeblik resultatet er kommet
tilbage.

pft,



--
Jesper Stocholm - www.stocholm.dk - www.asp-faq.dk
** De andre siger, at han er 16 **
Svar venligst til gruppen og ikke til mig privat !
Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html

 
 
Johnny E Jensen (27-03-2003)
Kommentar
Fra : Johnny E Jensen


Dato : 27-03-03 23:37

Hej Jesper

Nu ved jeg ikke hvilken SQL Server du henter fra, (jeg henter fra AS/400) og
her opretter jeg nogle temp-databaser - som kun vil være tilgængelige for
denne bruger p.g.af strukturen af AS/400 - Men MS Sql har også en
Temp-Database - så hvorfor ikke lade disse enorme mængder data blive
liggende på serveren.
/Johnny

"Jesper Stocholm"
<skal.du.absolut.vise.min.emailadresse.ved.svar@stocholm.invalid> wrote in
message news:Xns934673EA937DFspamstocholmdk@130.226.1.34...
> Jeg har lavet en lille hjælpe-app, der loader en SQL-fil og sender
> indholdet af den imod en databaseserver (TeraData). En del af kravene til
> applikationen er, at den skal kunne gemme resultatet af en forespørgsel
> (der altid er et recordset) i en fil på disk.
>
> Når jeg har siddet og tænkt lidt over, hvordan det skal skrues sammen, så
> vil jeg mene, at det giver mest mening af spørger brugeren om denne vil
> gemme resultatet _efter_ forespørgslen er blevet af viklet.
>
> Altså et flow som dette:
>
> Klik knap "Run query"
> If (Result = OK)
> Enable button "Store result"
>
> If (button is clicked)
> Use CmdDialog to navigate to and create a file
> end if
>
> Mit problem er nu - hvordan lagrer jeg resultatet imellem de to
> handlinger ? Skal jeg gemme resultatet i \temp og hvis det ønskes gemt -
> så kopiere filen fra \temp til den rigtige lokation ? Resultatet af
> forespørgslen er typisk på flere hundrede tusinde rækker, så det skal
> helst håndteres så optimalt som muligt. Hvis resultatet ikke skal gemmes
> er jeg ikke glad for at skulle håndtere dette i hukommelsen, og det bør
> vel helst fjernes fra applikationen i det øjeblik resultatet er kommet
> tilbage.
>
> pft,
>
>
>
> --
> Jesper Stocholm - www.stocholm.dk - www.asp-faq.dk
> ** De andre siger, at han er 16 **
> Svar venligst til gruppen og ikke til mig privat !
> Skriv under det du svarer på - www.usenet.dk/netikette/citatteknik.html



Jesper Stocholm (28-03-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 28-03-03 11:07

Johnny E Jensen wrote :

> Hej Jesper
>
> Nu ved jeg ikke hvilken SQL Server du henter fra, (jeg henter fra
> AS/400)

Data hentes fra et Teradata aDW.

> og her opretter jeg nogle temp-databaser - som kun vil være
> tilgængelige for denne bruger p.g.af strukturen af AS/400 - Men MS Sql
> har også en Temp-Database - så hvorfor ikke lade disse enorme mængder
> data blive liggende på serveren.

data skal efterfølgende importeres ind i et CRM-system, så jeg er _nødt_
til at hive dem ned på klienten. De kan ikke hentes direkte fra serveren
af dette CRM-system, da der er kommet nogle begrænsninger i den CLI-
version (bTeq), der normalt i disse situationer vil blive brugt til at
gøre det jeg ønsker.

Applikationens formål er dermed at lave et workaround, så der stadig kan
flyttes data fra DW til CRM-applikationen indtil den nye version af ODBC-
driveren kommer ... der har RTM engang næste år.



--
Jesper Stocholm - http://stocholm.dk
if you are competing with the darknet, you must compete on the darknet's
own terms: that is convenience and low cost rather than additional
security. ( http://crypto.stanford.edu/DRM2002/darknet5.doc )

Jesper Stocholm (28-03-2003)
Kommentar
Fra : Jesper Stocholm


Dato : 28-03-03 11:10

Johnny E Jensen wrote :

> Nu ved jeg ikke hvilken SQL Server du henter fra, (jeg henter fra
> AS/400) og her opretter jeg nogle temp-databaser - som kun vil være
> tilgængelige for denne bruger p.g.af strukturen af AS/400 - Men MS Sql
> har også en Temp-Database - så hvorfor ikke lade disse enorme mængder
> data blive liggende på serveren.

jeg kan i øvrigt fortælle, at jeg endte med at gemme data i \temp i det
øjeblik de kommer tilbage fra serveren. Dér ligger de så indtil brugeren
beder om at få gemt resultatet på et specifikt sted - hvortil data så
flyttes.

Der er selvfølgelig passende oprydningsrutiner, så temp ikke fyldes op.

I øvrigt: hvis jeg gemmer en fil i \temp, kan jeg så regne med, at den
forsvinder på et eller andet tidspunkt af sig selv ?

--
Jesper Stocholm - http://stocholm.dk
www.asp-faq.dk : FAQ for dk.edb.internet.webdesign.serverside.asp
www.usenet.dk/netikette/citatteknik.html : Skriv under det du svarer på
Svar til gruppen og ikke til mig privat !

Søg
Reklame
Statistik
Spørgsmål : 177558
Tips : 31968
Nyheder : 719565
Indlæg : 6408925
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste