I dette særtema ser vi på, hvordan cloud og AI bliver fundamentet for virksomhedernes digitale forretning, og hvordan de nye muligheder for automatisering og forretningsværdi kan udnyttes uden at miste overblik, sikkerhed og menneskelig kontrol.
øhh, som jeg sagde, så er den lidt tricky - derfor er den også lidt svær at forklare, men jeg skal prøve ;o)
Det nemmeste og mest oplagte ville være at lave en IIf(Forms!Form1!Check1;<0;>0) i kriteriert under [Avance], men det duer ikke i Access. Access kan ikke finde ud af at skifte kriteriet ud afhængigt af værdien af et felt på en formular. Derfor er man nødt til at holde kriteriet fast og så blot ændre feltet/værdien. Og det tog mig altså lige et par forsøg at få det til at virke. Ideen er at hvis Check1=true, så ganges [Avance] med -1, hvorfor kriteriet <0 i virkeligheden bliver til >0. Hvis Check1 = false, så ganges [Avance] blot med 1, sålede at kriteriet er <0.
Metoden duer lige netop i dette tilfælde, men er nok svær at overføre til andre tilfælde - men tankegangen er værd at tage med.
Jo det hjalp en del... og ja det giver lidt stof til eftertanke da jeg regnede med at jeg kunne bruge svaret til en lign. beregning hvor avance% skulle være mindre end 8 (<8), men det lader sig ikke gøre på denne måde...ÆÆÆVVVVV...
Kan du løse denne er der nye point til dig Proceduren er den samme bortset fra at checkboxen nu hedder 2 og feltet nu hedder [avance%]
Jeg har forsøgt at løse sidstnævnte ved at lave en kombobox der laver et opslag i en tabel der bare indeholder nogle poster der hedder.:
<10 <8 <6 <4 <2
i kriterie på queryen skev jeg så :
Like Forms![Form1]![Combo16] Or Forms![Form1]![Combo16] = null
men den viser da et null resultat. Jeg ville jo synes den skulle indsætte den valgte værdi i comboen feks. <8 det hjælper ej heller at tilføje en * (<8*) eller \"klamme\" det ind (\"<8\")/ (\"<8*\")
nogle ideer, som sagt point finder vi ud af med mingre det koster mere end de sølle 134 jeg har tilbage...
Nu kan jeg ikke helt huske hvor velbefærdet du er i VBA\'ens forunderlig verden, men jeg vil nok sige, at vi er over i en situation, hvor det er langt hurtigere at løse vha VBA. Ligeledes kan jeg heller ikke huske om du benytter Access 97 eller 2000 (sorry :) Nedenstående forslag benytter DAO, så det kan benyttes i bege versioner. Husk dog at sætte en reference til DAO, hvis du benytter Access 2000!
Mit forslag er:
Når brugeren har klikket på det han skal klikke på, skal du simpelthen ændre SQL\'en af din forespørgsel vha kode. Det er ganske simpelt:
Currentdb.querydefs(\"Query2\").SQL = \"Select * From [Tabel1] Where [Avance%] \" & IIF(Me!Check2, \"<8\",\">8\")
Derved er Query2\'s SQL ændret, således at den næste gang du åbner eller kører den, f.eks. ser således ud: Select * From [Tabel1] Where [Avance%] > 8
Udskift selv [Tabel1] og \"Query2\" med de respektive, ligesom der selvfølgelig også kan være flere kriterier eller flere tabeller i din forespørgsel. Men jeg håber, at du kan se ideen. Ellers vender du bare tilbage.
Dit forslag med Me!Combo16 er fint. Det burde virke. Du kan lægge koden på en trykknap eller du kan lægge den på AfterUpdate-eventen på comboboksen - derved skifter SQL automatisk når de vælger et kriterie på listen. (det tager kun et splitsekund, så det er ikke noget, som belastes hvis brugeren sidder og klikker løs på comboboksen)
Niels-> Du kan godt ændre en Querydef, selvom den er åben - det slår bare først gennem, når den har været lukket og åbnet igen - men hvor får du den underformular fra? Jeg mener ikke at Region har snakket om nogen underformular? Eller er det mig, der har overset noget?
Problemet er ikke større, end at du blot i din kode skal skrive: Me!Underformnavn.Form.Recordsource = \"Query2\" (Jeg ved ikke hvad din Underformular hedder)
Dette skal stå til sidst, således at koden kommer til at se nogenlunde sådan ud:
Currentdb.querydefs(\"Query2\").SQL = \"Select * From [Tabel1] Where [Avance%] \" & me!combo16 Me!Underformnavn.Form.Recordsource = \"Query2\"
Ja, jeg ved ikke om .requery er nok? Jeg synes, at jeg har oplevet flere situationer, hvor jeg netop var nødt til at assigne forespørgslen til recordsourc\'en manuelt før det virkede. Har du erfaring med det?
Til Region: Mht point, så giver du bare hvad du synes at spørgsmålet er værd - jeg vil ikke rippe dig for dine sidste 134 point, så omkring 30 point er fint nok :o) Jeg synes dog også at Niels fortjener lidt, da han jo langt hen ad vejen var på samme spor...
Fordellen ved at ændre querydef er at indstillingen er gent til næste gang du åbner formularen, eller hvis du skal skrive søgeresultattet ud på en rapport
Faren er at du ikke på forhånd ved hvordan din forespørgsel ser ud - hvis den er grundlag for flere formulare slår din søgning igennem her også.
Jeg synes let hele databasen bliver for uoverskulig, hvis jeg ændre i Querydef. Det skal være sådan at jeg ved at åbne forespørgslen kan se hvordan den ser ud. Så det har jeg desværre ingen erfaring med.
Niels, du har ret i, at der er visse farer ved at ændre querydef\'en. Men jeg mener at princip at man ALDRIG skal bruge den samme forespørgsel til flere forskellige formularer - man ender altid op med at der pludselig skal være en lille nuance-forskel på de 2 formularer. Dit alternativ med at skrive SQL\'en direkte i Recordsource\'en giver jo forøvrigt heller ikke mulighed for at bruge den samme forespørgsel i andre formularer, da den jo kun eksistere i den ene formular.
Hvis man bruger forespørgslen, f.eks. som underformular, som du gør Region, skal man selvfølgelig huske at \'nulstille\' forespørgslen inden formularen åbnes. Med \'nulstille\' mener jeg at man blot fjerner kriterierne: Currentdb.querydefs(\"Query2\").SQL = \"Select * From [Tabel1]\"
Der er også et performace-aspekt af det hele: Access afvikler gemte forespørgsler hurtigts - selvom Access skal bruge et par milliesekunder på at omskrive SQL\'en i forespørgslen, så vinder du dem tilbage mange gange, hvis forespørgslen er meget kompliceret og/eller der er store datamængder.
Endelig er der problemet med PassThrough-forespørgsler, hvor man via ODBC sender en SQL-streng afsted. Her er det ikke muligt at benytte kriterier med form-referencer, som vi gør det her. Dvs, at du er nødt til at øndre Querydef\'en for at benytte PassThrough-forespørgsler, som er afhængige af brugerens indtastninger på en formular.
Dette var blot et par tanker for og imod ændring af querydefs :o)
Hvis jeg skal bruge søgningen senere opretter jeg nogle tempTabeller som raporter o.a. er baseret på. Insert into, update, delete From tempTabel.
Det giver en del performance på netværk, at man kun forespørger de samme data én gang. Jeg har desuden også haft held med at gemme SQLstrenge i en tabel - Det giver mulighed for at se sidste eller forrige søgning.
Private Sub Combo16_AfterUpdate() CurrentDb.QueryDefs(\"qvis\").SQL = \"SELECT * from [vis] WHERE [avance%]\" & Me!Combo16 Me!qvis1subform.Form.recorsource = \"qvis\" End Sub
den siger at den ikke kan finde feltet qvis1subform der refereres til i udtrykket
Det navn, som du skal skrive er det navn, som din underformular-kontrolelement har. Det er ikke nødvendigvis det samme som navnet på den formular, som du benytter som underformular. Stil dig i design på hovedformularen og klik én gang på underformularen og se hvilket navn, der står i egenskaberne.
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.
Ny bruger
Nybegynder
Opret
Preview
