Fileter på blok er langsom

Hvilken version af C5 bruger du?

Hvorfor bruger du ikke funktionen "PrevMth"?

Dit filter undersøger samtlige poster, prøv at lav en Search løkke der udvælger den sidste måned istedet!

Det er en ver. 4.2.1.

Tak for hintet med PrevMth

Umiddelbart skal jeg til at kode en hel del hvis jeg skal lave en search som skal ind i form-blokken og skal kunne redigeres?!

Hvad mener du egentlig med "autoarkivere" fra en form?
Er det et under menupkt. eller....?

Nu ved jeg jo ikke hverken hvilken tabel eller hvilken form du sidder og arbejder med, men en Search løkke til at udvælge data fra en bestemt tabel i et bestemt dato interval fylder ganske få kodelinier!
Skal du have koden så giv mig:
Tabelnavn, Form og søge kriterier(felter).
....og selvfølgelig svar på de to spørgsmål i starten! :-)

Kartoteket jeg arbejder i er CustJournal og formen er en PBSLEV_FakturaStatus (Hvis du kender det)

Jeg kigger på PBSLEV_Opkræv og Date_ i CustJournal og har oprettet et index (PbsDateIdx -> PBSLEV_Opkræv, Date_)

Jeg skal bruge dem der har PBS_Opkræv=1 og hvor datoen er inden for en måned (ca.)

Kører du på en SQL-DB eller en Native-db ?

SEARCH CustJournal USING PbsDateIdx
      WHERE PBS_Opkræv == 1 AND
            Date_      >= PrevMth(Today())
END

Ovenstående udvælger de ønskede (felttype på PBS_Opkræv ?).

Hvor du skal placere koden og hvad du gør med de udvalgte kan jeg ikke svare på da du jo ikke svarede på de 2 spørgsmål øverst i sidste indlæg!

Var det svar nok?

med autoarkivering mente jeg bare at den ikke skal vise records ældre end f.eks 30 dage

det er ikke en knap men noget der skal ske npr formen kaldes ... så mon ikke det skal være i init'en?!

jasman: det er en sql

Se det er jo så en anden sag - prøv følgende:

Indsæt følgende While løkke i Filter på blokken:

WHILE CustJournal.PBS_Opkræv <> 1 OR
      Date_ <= PrevMth(Today())
      RETURN 0
END

Når det er en SQL-backend så skulle du lade den gøre arbejdet med at afgøre hvilke poster der skal vises i formen.
Filter-metoden er meget langsom da, det først afgøres om posten skal vises når den ER hentet. Så det vil jo ske for samtlige records du henter.

Hvis du nu lod SQL-backenden om opgaven, er jeg sikker på, at svartiden ville blive noget bedre.

Prøv at undersøge SQL-makrobiblioteket, og du vil opdage, at man faktisk kan fodre en form med en SQL-WHERE CLAUSE.

Lokalmakroen hedder

#SQLSetWhereCondition

Og den tager tabelnavn som første parameter
og where-clausen som anden parameter

Et temp-index vil også være en løsning.

Hehe.
Jeg var ellers ved at lave et kodeeksempel til dig. :)
Kan du ikke lige vise det kode som du har lavet her, så andre evt. kan få glæde af det også ?

PFT.

Jeg har selv godt nok på en XAL brugt metoden til at nedbringe svartiden i en form, som gik på tværs af en hulens masse regnskaber for at samle data sammen. Vi gik fra 1.5 - 3 min, ned til omkring 3 sek.

Så man kan i nogle tilfælde hente nogle ret kraftige performanceforbedringer.

hehe har faktisk ikke koden ... men kunne se det ville virke ... kunden ombestemte sig og ville faktisk bare starte i formen der hvor datoen var en måned gammel og så have mulighed for at scrolle op ... så opgaven blev løst med en #Frm_FIND og en SET CustJournal.Date_ :-)

Ok.

Jamen så må jeg hellere komme med et eksempel :0)
Godt nok taget fra XAL-verdenen, men det skulle også virke i c5 da kernen jo stort set er magen til.

"
#SQLSetWhereCondition er af en eller anden grund ikke anvendt i standard applikationen, selvom den i mange tilfælde ville kunne eliminere brugen af temp-kartoteker eller suspekte filter-triggere.

Vi tager et eksempel .. koden kan f.eks. ligge i INIT-triggeren :

  #MacroLoad(FORMS)
  #MacroLoad(SQL)

  #FRM_INDEX(StockTable,GroupItemIdx)

  #SQLSetWhereCondition(StockTable,
    #SQLFieldName(StockTable,SalesPrice) + ' > ' + #SQL_INT(1) + ' AND ' +
    #SQLFieldName(StockTable,ItemGroup)  + ' = ' + #SQL_STR('20')
  )

  #FRM_SEARCH(StockTable)

Her sætter vi det op så XAL'en præsenterer posterne i StockTable sorteret efter GroupItemIdx hvor gruppen er lig '20' og salgsprisen er større end 1 krone.

SQL-mæssigt bliver det til :

  SELECT ROWNUMBER,LASTCHANGED,ITEMGROUP,ITEMNUMBER,ITEMNAME, …… STDCR,ROWID
  FROM STOCKTABLE
  WHERE DATASET = ‘DAT' AND SALESPRICE > 1 AND ITEMGROUP = '20'
  ORDER BY DATASET,ITEMGROUP,ITEMNUMBER,ROWNUMBER
"

Til jasman:

Er #SQLSetWhereCondition ikke aktiv indtil man kører #SQLClearWhereCondition ?

D.v.s. hvis du springer fra din form i eksemplet til en anden form med StockTable vil #SQLSetWhereCondition stadig være aktiv. Det kan selvfølgelig både være godt og skidt - men det kan forklare hvorfor det ikke er benyttet i standard.

Ellers kan jeg kun tilslutte mig din løsning.

Men hvordan ville du få en dato indover her? altså hvis der skal sorteres på dato?

f.eks. Today() - 45

Lav dog et ganske almindeligt index. Det er både hurtigt og nemt, og så slipper man for at bøvle med SQL-koden.

Jeg vil helt sikkert bruge et tmp-index til at løse dette. Filter vil aldrig komme til at performe godt uanset hvilken database der anvendes.

mariaf:
Jeg har lavet et index der indeksere på PBSLEV_Opkræv og på Date_ ... jeg mener ikke jeg kan lave et index der har begrænsning på datoen?!

Broholm:
Jeg ville faktisk helt undgå at benytte tmp-index'et da jeg er af den opfattelse at der MÅ være en anden udvej :-)

Lav et indeks på dit arkivfelt, og lad en kørsel sørge for at det blive opdateret hver morgen, så det kun er poster over 1 måned gamle, der har feltet aktivt. Kørslen kan også sagtens ligge i init-triggeren, hvsi det ikke er alt for mange poster, den skal igennem