Archief - .NET Acces Database Query

Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.

fat-beavis

Legacy Member
Hallo,


Even kort voorstellen met wat voor project ik bezig ben.

Het is voor een bedrijf die het vervoer regelt voor ziekenwagens.
Dus per dag komen de ambulanciers met de bonnen aan de administratie die dan op hun beurt alles in ( mijn ) applicatie invoert, de applicatie zorgt voor de factuur en voila.
Voor de rest moet ik mij niets aantrekken
Op een factuur staan gewoon de gegevens van het bedrijf, van de patient en de gegevens van de opdracht zelf ( hoeveel kilometer, dag / nacht tarief , noem maar op )

Wat op de factuur komt wordt MANUEEL door een medewerker ingetypt.

Nu vraag ik me eigenlijk zo best af op welke manier je best een acces database Query uitvoert.

Als het programma opstart laadt het al zijn klanten uit de acces db.
Wat ik nu momenteel doe is alles inladen, en dan via lists ( of Patient bv ) bewaren.

Om dan in het programma zoekopdrachten uit te voeren ( bijvoorbeeld zoek Patient geboren op 12/01/1958 ) zoek ik in de lijst met behulp van een LINQ Query.

Is dit acceptabel ? Ik bedoel qua performantie.
Waarom ik hiervoor gekozen heb ik dat het programma zijn database inlaadt wanneer het wordt opgestart en dus mijn voor mijn Query's niet steeds de database hoef aan te spreken.

Nadeel is wel qua updates natuurlijk. Er zullen maar 2 personen zijn die dit programma gebruiken.

Zou ik een automatische auto-update voorzien ? Die mijn programma iedere x minuten vernieuwd?

Ik heb geen hulp nodig met de code maar wat tips over hoe het best zou aanpakken voor een goede performantie.

Alvast Bedankt ! :applause:

fat-beavis

Legacy Member
Neen , dat is gewoon een vereiste vanuit de Business zelf. SQL oid was geen optie. Moest en zou Acces zijn

metalleke

Legacy Member
fat-beavis zei:
Neen , dat is gewoon een vereiste vanuit de Business zelf. SQL oid was geen optie. Moest en zou Acces zijn

Ale tof als de business al technische vereisten op gaat leggen.
Anyways, maak eerst een prototype en kijk of je performantie ok is?

Strikeh

Legacy Member
Mijn inziens lijkt me dit toch niet zo'n goed idee om al de data in 1 keer in te laden.
Je gaat zo wel eens tegen concurreny problemen aanlopen (ook al werk je er maar met 2 aan).
Als je aan een dossier van een klant aan het werken bent, je wil dit opslagen, ben je niet zeker dat dit niet ondertussen al aangepast is, en ga je mogelijk data verliezen.
Bovendien lijkt me dit ook niet echt performant om al de data in het geheugen bij te houden.

Waarom ik hiervoor gekozen heb ik dat het programma zijn database inlaadt wanneer het wordt opgestart en dus mijn voor mijn Query's niet steeds de database hoef aan te spreken.

Waarom is dat een probleem om de database aan te spreken voor elke query ?

Recipe4hate

Legacy Member
Is het niet net beter om met een systeem te werken dat enkel data gaat lezen of schrijven wanneer het nodig is?
Die database gaat het niet erg vinden als je de hele tijd verbinding maakt, denk ik zo...

Voor SQL heeft dotnet hier zelfs veel functionaliteit voor. Voor Access weet ik 't niet.
Het archief is een bevroren moment uit een vorige versie van dit forum, met andere regels en andere bazen. Deze posts weerspiegelen op geen enkele manier onze huidige ideeën, waarden of wereldbeelden en zijn op sommige plaatsen gecensureerd wegens ontoelaatbaar. Veel zijn in een andere tijdsgeest gemaakt, al dan niet ironisch - zoals in het ironische subforum Off-Topic - en zouden op dit moment niet meer gepost (mogen) worden. Toch bieden we dit archief nog graag aan als informatiedatabank en naslagwerk. Lees er hier meer over of start een gesprek met anderen.
Terug
Bovenaan