Requery

  • Onderwerp starter Onderwerp starter spw
  • Startdatum Startdatum
Status
Niet open voor verdere reacties.
Ik heb geen flauw idee wat je aan het doen bent. Kun je niet een db posten met wat dummydata?
En die 'extra duidelijkheid' die je noteert ("De content van het veld wordt niet aangepast") helpt natuurlijk ook niet.... de hele grap is toch juist dat de hele actie zo lang duurt omdat je de datum aanpast?
Een requery 'op basis van een record'? Je doet een requery op basis van de recordset. Als daar één record in zit, dan wordt dat getoond. Maar als het uitvoeren van de oorspronkelijke query ook 4 seconden duurt, geldt dat waarschijnlijk ook voor de requery.
Heb je daar last van, gebruik dan een tijdelijke tabel voor je formulier.
 
Ik snap er nog steeds niks van, want de naamgeving van je tabellen zegt mij helemaal niks en dan is het lastig 'inleven'. Een tabel met de naam [Naam] zou in mijn optiek Klanten bevatten, en zeker geen ordernummers. Daarnaast zie ik de relatie niet tussen order 100 (A1) en order 101 (A2). In mijn beleving kan een order uit suborders bestaan, maar die hebben dan hetzelfde ordernummer. Kun je er geen voorbeeldje bij doen?
 
Echt, ik dacht dat ik wat van databases wist, maar hier snap ik nog steeds helemaal niks van.... Als je alleen records bij wilt werken op basis van A1 en A2, dan worden er dus geen duizenden records bijgewerkt. Ik snap je probleem dus niet. En die knop die je gebruikt, zou natuurlijk gelijk de gewenste records bij moeten werken, en dat zou je qua tijd nauwelijks mogen merken.
 
spw zei:
Ohja, in het 'echte' voorbeeld open ik eerst een ander formulier om datumwijziging uit te voeren omdat ik anders de melding krijg "recordset is not updateable". Vanwege de query met verschillende tabellen.
Klik om te vergroten...
Dat verbaast me niets gezien de constructie. Je extra uitlegt helpt mij in ieder geval nog steeds niet; ik heb nog geen flauw idee wat je nu precies aan het doen bent. Als ik er een gok naar moet slaan, ben je een workflow voor de productie van een apparaat o.i.d. aan het maken op basis van een bestelling, waarbij je stap B pas kan doen als stap A klaar is. En als A opschuift in de tijd, dan moet B ook opschuiven. En dat maak je dan zo ingewikkeld, dat het mij nog steeds behoorlijk duizelt...

Maar je vraag hoe ik het zou oplossen.... Dat kan ik dus niet zeggen zonder te weten wat nu precies de bedoeling is. Ik kan wel wat gaan roepen, maar dat lijkt mij in dit stadium behoorlijk zinloos. Als ik gelijk heb, en je het dus over één productieproces hebt met afhankelijke subprocessen, dan is het m.i. behoorlijk simpel (en snel) op te lossen. Om te beginnen gebruik je dan een hoofdformulier op basis van het hoofdproces (A, B etc). Op dat hoofdformulier een subformulier met de gekoppelde subprocessen (A1, A2 bij proces A, B1 en B2 bij proces B). In het hoofdformulier heb je dan de officiele startdatum, en het subformulier gebruikt die startdatum + # als startdatum. Simpele actie die je in het subformulier kunt inbouwen. Idem voor A2. De Einddatum zou ik sowieso weggooien en vervangen door een numeriek veld [Productietijd]. De eindtijd wordt immers bepaald doordat je vanaf de startdatum # dagen nodig hebt voor de productie. Anders zou je de einddatum niet óók moeten verhogen. Doordat je de einddatum dus simpel berekent ([Einddatum] = [Startdatum] + [Productietijd]) hoef je maar één datum aan te passen als die verandert. Idem dus ook voor de subformulieren.
Het herberekenen van het subformulier is dan ook simpel, want zodra je de startdatum verandert (waarom niet gewoon met de DatePicker?) dan gebruik je de OnClick om de startdatum over te zetten naar de subformulieren. Die van zichzelf dus ook die datumvelden hebben. En niks queries die niet kunnen updaten of een requery die niet werkt.
 
We hebben veel meer aan een database (met dummy data) want het blijft nog steeds een gokspelletje zo. Want ik begrijp het proces nog steeds niet.
spw zei:
Je kan het idd vergelijken met een productieproces. Enkel de productietijd is niet te bepalen.Soms 2 dagen soms 5 dagen of x dagen.
Klik om te vergroten...
Bedoel je hiermee dat je de processen niet gelijktijdig inplant? Dus dat de eerste vervolgstap pas wordt ingepland als de eerste stap klaar is? want anders begrijp ik het niet. Als je een nieuw proces inplant met verschillende vervolgstappen, dan bekijk je per proces hoelang een stap duurt. Dat kan 2 dagen zijn, 5 dagen, of anders. Maakt toch niet uit? Je begint met de eerste stap, bepaalt het aantal dagen, daar rolt een einddatum uit en dus automatisch een begindatum voor de 1e vervolgstap, en zo ga je door voor alle stappen.
Of: je plant maar één stap, vult een einddatum in en krijgt dan automatisch de eerste vervolgstap met begindatum+termijn. Hoe dan ook: een planning is precies dat: een overzicht van te verwachten productiedatums. En dus niet de feitelijke datums. Daarom zie ik dus niet in waarom je de doorlooptijd niet op deze manier kan invoeren.

Voor het bijwerken van de processen maak je dan een functie die bij het aanpassen van de doorlooptijd alle andere datums opnieuw berekent in in de tabel zet. Want hoewel zo'n klusje in Excel een hele simpele formule is, moet je daar in Access wat meer voor doen omdat onderlinge records nu eenmaal niet gekoppeld kunnen zijn.
 
Doe ons een lol en haal die quoot weg, want dat is natuurlijk nergens voor nodig, mijn berichtje staat er pal boven.
Je andere vraag (had je beter een eigen vraag voor kunnen maken, maar goed) zou ik sowieso niet op deze manier doen. Gebruik gewoon tekstvelden, en een (dubbel)klik actie FollowHyperlink, dat werkt veel beter.
Je kunt met een Environ opdracht, of de SpecialFolders collectie, standaardmappen opvragen. De SpecialFolder (My Documents) bijvoorbeeld kijkt voor elke gebruiker naar de eigen map Mijn Documenten.
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan