16. juni 2004 - 11:51Der er
19 kommentarer og 1 løsning
frasortering af records
Jeg har en form med 650 poster der indeholder de faste data som kundenummer, firmanavn, adresse osv. Ligeledes har jeg en underform som indeholder en record for hver ubetalt regning. De to forms er bundet sammen ved kundenummeret. Mit problem består i at jeg ikke ønsker at se alle 650 poster hvis der ikke er nogle ubetalte regninger ved den enkelte kunde. Derfor ønsker jeg at ved indgang til formen, at sortere alle de poster fra, der ikke har nogle ubetalte regninger... håber det er gjort forståeligt...
Hvis tabellen Regninger indeholder både betalte og ubetalte regninger, skal min SQL ændres til: Select * From [tblKunder] Where kundenummer Not In (Select Kundenummer From [tblRegninger] Where Betalt is Null)
Kriteriet i sub-select'en afhænger selvfølgelig af hvordan din tabel ser ud....
nu bliver siden loaded rent grafisk, men når den skal udføre de sidste beregninger, kører den hele processbaren igennem og stopper bare der!
Private Sub Form_Load() Me.Filter = "kundenr Not In (Select Kundenr From [Q_IkkeBetalt])" Me.FilterOn = True End Sub
Det virker lidt som om filter-funktionen er ufatteligt langsom. Er dette tilfældet? Er det bedre at basere hele skidtet på en ny forespørgesel, som i begge nævnte indledningsvist!?
Hvis datamængderne er store eller hvis tabeller ikke er indekseret eller hvis Q_IkkeBetalt ikke er optimeret korrekt, så kan det godt tage tid. Især hvis formularen er sorteret ved opstart - så skal denne sortering foretages 2 gange.
Der er flere ting, som spiller ind. Det er svært at svare eksakt på, når jeg ikke kender dit system
Er select * from a where b not in (select c from d) i øvrigt ikke ekstremt buggy/skrøbelig? Jeg har brugt den nogle dage med succes og efter jeg nu legede lidt med primary keys på de involverede tabeller og sat dem tilbage til samme indstillinger som før virker det pludselig ikke! Oi jeg er ved at være træt af Access!
select * from a where b not in (select c from d) er en god struktur, da den ikke piller ved din oprindelige select - kun på kriteriet.
Hvis du ændre på de unikke felter, skal du selvfølgelig sørge for at forespørgslen stadig arbejder med de rigtige felter...dette ville også gælde selvom du benytter joins i din forespørgsel.
jo, men alt jeg gjorde var blot at tilføje en primary key og fjerne den igen, tabllen er fuldstændig identisk hvad angår struktur og data i forhold til før, men pludselig giver forespørgslen ingen resultater!
nej, ikke helt... Jeg synes nu at den ekstra select hiver hastigheden HELT enormt ned. Det tog 4 sekunder at udføre den gamle beregning, nu tager det omkring 30 sek... :( Jeg forsøger stadig at finde en alternativ løsning.
Hvis jeg benytter et filter, tager det endnu længere tid, dog virker begge metoder helt perfekt...
Synes godt om
Ny brugerNybegynder
Din løsning...
Tilladte BB-code-tags: [b]fed[/b] [i]kursiv[/i] [u]understreget[/u] Web- og emailadresser omdannes automatisk til links. Der sættes "nofollow" på alle links.
