[Access] meer dan 1000 in listboxes etc. Geeft dit problemen

[Verwijderd]

We hebben hier een Access database met meerdere frond-ends op een back-end. De frond-ends staan locaal, en de back-end op het netwerk.

Frond-end:
- Access 2000 sr2
- 5Mb
- 15 gebruikers max 30
- tabellen gelinkt, of sommige worden gecopieerd naar tabel in frond-end.

Back-end:
- Access 97 (wordt overgezet naar 2000)
- 123 Mb, gecompact 35 mb
- iedere ochtend update met nieuwe orders en compact db

In de applicatie moet een order uit een lijst met orders gekozen worden. Deze lijst was klein,maar door de implementatie in een groter werkgebied kunnen er meer dan 2000 werkorders aanwezig zijn.

Probleem
De werkorder wordt gekozen mbv een combobox, maar dit geeft problemen. Er ontbreken records aan het einde van de lijst, en verschillende criteria in de bronquery van de combobox zijn niet meer mogelijk.

Kan het zijn dat dit ligt aan het feit dat er zo veel record zijn??? Vroeger (minder records) was dit nooit.

Standaard laat de applicatie (instelling onder options - edit/find) tabellen met meer dan 1000 records niet zien. Ik heb dit veranderd naar 25000, maar dit heeft geen resultaat.

De back-end loopt vaak vast, er komt dan een melding dat de applicatie niet in geschikt formaat is, of beschadigd. Er wordt de optie geboden om de db te repairen. Na de laatste crash zijn recenterlijk veel gegevens mee verloren gegaan.

Ook lijkt het of de db na iedere crash instabieler wordt???? maar de gegevensvalidaties geven geen problemen aan.... ???

Oplossing
De volgende oorzaken kan ik bedenken, maar niet uitsluiten of bevestigen:
- back-end te groot (123 MB, niet waarschijnlijk, netwerk heeft genoeg ruimte)
- netwerk te traag, applicatie geeft error: "Disk or network error" time-out.
- ????

[whoami]

Access is nu al niet de te preferen keuze als het gaat om een databasesysteem waar er meerdere concurrente gebruikers zijn. Je kiest dan beter voor SQL Server, MSDE (SQL Server engine), PostgreSQL, oid.
Die melding die je krijgt over 'de db is in verkeerd formaat oid', kan te maken hebben met dit feit. (Meerdere users).

Een combobox of listbox met meer dan 1000 items is allesbehalve gebruiksvriendelijk te noemen. Is er geen enkele mogelijkheid om dat aantal te beperken?

Is je query wel performant? Worden er indexes gebruikt?

[ Voor 13% gewijzigd door whoami op 01-04-2003 13:24 ]

[Boss]

Die combobox kan prima, hoor. Ik heb een klant met 1000-en items in een combobox, die hij over een netwerk opent. Gaat prima. Het is ook zeker gebruiksvriendelijk, aangezien dit een lange lijst is met namen (achternaam, voornaam) en hij zo snel de juiste kan openen zonder een ranzige zoek-functie te hoeven gebruiken.

De opdeling van front/back end klinkt heel wazig, hoe jij het gedaan hebt. Tabellen heen en weer kopiëren? Lijkt me niet zo lekker.
20-30 man moet nog net te doen zijn, als ze maar niet echt tegelijkertijd aan het werk zijn.

Maak ook eens een nieuwe, lege database en importeer dan alle tabellen uit je back-end er opnieuw in. Dan heb je alles weer helemaal netjes staan.

Een database-server (MS SQL of een open-source variant) zou ik je wel gaan aanraden als je problemen blijft houden en/of meer gebruikers krijgt,

[Verwijderd]

whoami schreef op 01 April 2003 @ 13:23:
Een combobox of listbox met meer dan 1000 items is allesbehalve gebruiksvriendelijk te noemen. Is er geen enkele mogelijkheid om dat aantal te beperken?

Is je query wel performant? Worden er indexes gebruikt?

De gebruikers typen de eerste paar cijfers van de order in, en de combobox loopt door de mogelijkheden tot er maar 1 over is. Vaak hoeven zo maar een paar cijfer ingetikt te worden ipv het gehele ordernummer.

Beperken van het aantal orders is geen optie, geen criteria zoals vervaldatum oid beschikbaar die voldoen.

De queries lopen goed. Momenteel ben ik bezig om te kijken of de indexes goed gebruikt worden. Ik heb dat gehele ding zelf gebouwd, maar daar heb ik nog niet zo veel kennis van.

[StevenK]

15-30 gebruikers -> dan zou ik heel dringend migreren naar SQL.

[Verwijderd]

Boss schreef op 01 April 2003 @ 15:04:
De opdeling van front/back end klinkt heel wazig, hoe jij het gedaan hebt. Tabellen heen en weer kopiëren? Lijkt me niet zo lekker.

Dit heb ik bewust gedaan bij het opstarten van de frond-end om een aantal tabellen beschikbaar te maken. Hier kunnen dan analyses op uitgevoerd worden, dit kost anders teveel tijd over het netwerp ipv local.

Ze worden niet terug gekopieerd

[whoami]

StevenK schreef op 01 April 2003 @ 17:16:
15-30 gebruikers -> dan zou ik heel dringend migreren naar SQL.

Access gebruikt ook SQL. Alle relationele databases gebruiken SQL.

Jij bedoelt natuurlijk SQL Server.

[Verwijderd]

StevenK schreef op 01 April 2003 @ 17:16:
15-30 gebruikers -> dan zou ik heel dringend migreren naar SQL.

Het is een groot bedrijf, en de applicatie is een primaire productietool. Middelen genoeg, maar waar ligt de oorzaak??

Ze hebben wel een SQL-server, maar gebruiken deze niet. Ik kan er gebruik van maken, maar weet niet wat hier bij komt kijken...... ?? Haal ik me zo niet meer op me nek??

Hoeveel komt erbij kijken om de db over te zetten naar een SQL-server?? Ik weet dat dit in Access onder Upload oid zit, maar wat daarna??

[ Voor 27% gewijzigd door Verwijderd op 01-04-2003 17:23 ]

[whoami]

In SQL Server kan je je Access DB importeren.
Ik geloof wel dat je dan zelf wel nog alle indexen en relaties moet aanmaken. Het is dan eigenlijk ook het beste om zowiezo eens alle tabellen na te gaan en te kijken of alle datatypes en veldlengtes wel correct zijn.

[Verwijderd]

whoami schreef op 01 April 2003 @ 17:20:
In SQL Server kan je je Access DB importeren.
Ik geloof wel dat je dan zelf wel nog alle indexen en relaties moet aanmaken. Het is dan eigenlijk ook het beste om zowiezo eens alle tabellen na te gaan en te kijken of alle datatypes en veldlengtes wel correct zijn.

Zijn de relaties niet over te nemen uit Access.

De SQL-server bevat dan toch alleen de Back-end?? of ook de frond-end?

De tabellen kloppen que veldlengtes en datatypen. Hier is niet veel variatie mogelijk omdat de brondata uit een andere (MRP) systeem komt, en gelijke veldlengtes en datatypen gebruik.

[whoami]

[nohtml]

Verwijderd schreef op 01 April 2003 @ 17:26:
[...]


Zijn de relaties niet over te nemen uit Access.

Ik heb ooit eens een Access DB op die manier geimporteerd, en voor zover ik me herinner heb ik de relaties in SQL Server opnieuw moeten aanmaken.

De SQL-server bevat dan toch alleen de Back-end?? of ook de frond-end?

De back end.
Ik snap zowiezo niet waarom je die gegevens ook nog eens op de front-end gaat gaan zetten. Je zegt dat je daarmee netwerktraffic uitspaart, maar als je iedere dag die gegevens gaat gaan kopieren, dan heb je die load toch.
Het beste is -imho- om de DB op de back end te laten, en geen gegevens te dupliceren op de front end.

[StevenK]

whoami schreef op 01 April 2003 @ 17:17:

[...]


Access gebruikt ook SQL. Alle relationele databases gebruiken SQL.

Als je dan zonodig bijdehand moet zijn, doe het dan goed.

Access gebruikt geen SQL. Weliswaar kan de programmeur SQL gebruiken, maar Access gebruikt de JET engine.

Daarnaast lijkt de term 'upgrade naar SQL' in deze context duidelijk op een SQL server slaan.

[StevenK]

Verwijderd schreef op 01 april 2003 @ 17:19:
[...]

Het is een groot bedrijf, en de applicatie is een primaire productietool. Middelen genoeg, maar waar ligt de oorzaak??

Ze hebben wel een SQL-server, maar gebruiken deze niet. Ik kan er gebruik van maken, maar weet niet wat hier bij komt kijken...... ?? Haal ik me zo niet meer op me nek??

Hoeveel komt erbij kijken om de db over te zetten naar een SQL-server?? Ik weet dat dit in Access onder Upload oid zit, maar wat daarna??

Met alleen de upsizing wizard ben je er niet direct. Vaak moet je toch het één en ander in je code veranderen voor het goed werkt.

Maar daarvan afgezien is het wel zo dat je met een dagje werk de boel werkend kunt hebben.

Ik heb dat ook een paar keer gedaan, en je loopt tegen een aantal problemen aan waar de recordset objecten net iets anders werken. Ook het feit dat Access geen key-veld eist, levert problemen op.

Heb je dat éénmaal voor elkaar, dan kun je daarna meer performance creëren, door o.a. goed gebruik van Stored Procedures en Views.

Ook zou je een nieuwe interface kunnen ontwikkelen, die webbased is.

[StevenK]

Verwijderd schreef op 01 april 2003 @ 17:26:
[...]


Zijn de relaties niet over te nemen uit Access.

De SQL-server bevat dan toch alleen de Back-end?? of ook de frond-end?

De tabellen kloppen que veldlengtes en datatypen. Hier is niet veel variatie mogelijk omdat de brondata uit een andere (MRP) systeem komt, en gelijke veldlengtes en datatypen gebruik.

De tabellen en relaties worden met de wizard netjes overgezet. Overigens kun je de SQL server naast de backend ook voor de business-logic gebruiken, door verstandig gebruik te maken van vooral Stored Procedures, Views en triggers.

[whoami]

StevenK schreef op 01 April 2003 @ 18:35:
[...]

Access gebruikt geen SQL. Weliswaar kan de programmeur SQL gebruiken, maar Access gebruikt de JET engine.

Ik had het dan ook niet op de onderliggende engine. (SQL is trouwens geen engine, maar een DDL DML taal).
Ik doelde op het feit dat je in Access mbhv SQL ook tabellen kunt creeëren, aanpassen, gegevens inserten, updaten en selecteren.

Daarnaast lijkt de term 'upgrade naar SQL' in deze context duidelijk op een SQL server slaan.

Dat zei ik toch al?

Mag ik je trouwens eens wijzen op het bestaan van de edit-knop?

[Verwijderd]

Om even terug te komen op de aanvankelijke vraag. Database repareren kan nooit kwaad. Bij de reparatie van de database worden alle indexen weer eens goed gezet. Over indexen besproken, die helpen de database bij het zoeken en sorteren van de regels in een tabel. Als je veel orders moet tonen (die waarschijnlijk ook gesorteerd zijn) zou je in ieder geval een index moeten zetten op ordernummer.

Iedereen doet hier zo makkelijk over een upgrade naar SQL-server, maar dat is niet zo eenvoudig als iedereen het hier laat weten. Het importeren van de data in de SQL-server en het aanmaken van indexen is nog niet zozeer een probleem. Het probleem ligt waarschijnlijk veel meer in de frontend applicatie. Als je het al hebt over relaties in je Access-database denk ik dat de front-end van nog veel meer Access-typische dingen bevat. De Types van SQL-server komen niet overeen met de types van Access, de SQL-taal die je moet gebruiken is niet gelijk (denk maar eens aan hoe je een datum meegeeft aan een query in Access en een datum in een query van SQL-server).

De grootte van je Access-database is nog niet alarmerend. Pas als je database richting de 2 Gieg gaat moet je actie ondernemen (meerdere backend databases maken bijvoorbeeld). Waar je wel naar moet kijken is upgraden naar Access 2000, en een update uitvoeren van je jet-engine. Als je met 97 werkt en blijft werken moet je jet-versie 3.51 hebben, elke versie daarvoor zorgt voor instabiliteit.

Succes ermee!

[VisionMaster]

Verwijderd schreef op 02 april 2003 @ 09:46:
...

...

De Types van SQL-server komen niet overeen met de types van Access, de SQL-taal die je moet gebruiken is niet gelijk (denk maar eens aan hoe je een datum meegeeft aan een query in Access en een datum in een query van SQL-server).

De grootte van je Access-database is nog niet alarmerend. Pas als je database richting de 2 Gieg gaat moet je actie ondernemen (meerdere backend databases maken bijvoorbeeld). Waar je wel naar moet kijken is upgraden naar Access 2000, en een update uitvoeren van je jet-engine. Als je met 97 werkt en blijft werken moet je jet-versie 3.51 hebben, elke versie daarvoor zorgt voor instabiliteit.

Succes ermee!

*zucht
ik begin bij de types:
Ik heb een project gehad die met dezelfde programmatuur (front end geschreven in Delphi) een Access mdb, Sybase server en Oracle server moest kunnen over bruggen. We moesten heel erg oppassen welke types we gebruikten. Maar je kan de gestandardiseerde types wel gewoon cross-database gebruiken. Vaak hebben de types een andere naam en zijn ze des al niet te min hetzelfde qua omvang. Voor een datum veld kan je de queries nog aanpassen zonodig of je kan op je server je default datetime format bijwerken.

Access databases zijn niet direct grote productie databases. Ze kunnen groeien tot je max file grote op je filesystem. Als dat 2 gig is dan 2 gig.
Maar ...
Een access database kan met een ongunstige structuur (1 tabel) boven de 50 MB wel eens rot gaan. De Jet engine is niet op omvangen berekent die met meer om zullen gaan. Goed de nieuwe Jet engine zal het ongetwijfeld beter doen. Maar 2 gig in een mdb, sorry maar het is een onmogelijk om er dan nog met een redelijke performance je gegevens uit te krijgen.
Je kan echt wel Inserten tot je aan de 2 gig bent, maar dan houdt het op. Je queries zouden er oneindig lang over kunnen doen, zelfs bij eenvoudige.
Ook als je structuur optimaal is dan hou ik zelf al aan (uit werk ervaring) dat boven de 50 MB tricky kan zijn. Boven de 100MB moet men dan echt een db compress gaan doen om de verwijderde records er echt uit te halen.

Er zijn diverse oplossing nog mogelijk met Access.
-Je zou je front end kunnen aanlaten sluiten met iets anders als Access.
-Je zou kritisch moeten kijken naar je structuur en indexen (teveel indexen is ook performance en stabiliteit onderdrukkend)
-Allerlei leuke ideeen uit dit topic

[Verwijderd]

VisionMaster, je kunt wel zuchten, maar Access-databases gaan niet stuk als ze groter dan 100 Mb zijn. Inserten, selecteren en dergelijke gaan niet traag omdat de database groot is, maar omdat sommige ontwikkelaars het niet op de goede manier doen. Ik werk met Access-databases van soms wel meer dan 1 gieg aan data en dat levert eigenlijk haast nooit problemen op.

Als je van te voren al bedenkt dat een front-end met verschillende databases moet gaan werken is dat geen enkel probleem. Ik schrijf (bijna) al mijn database applicaties 3-tier, dan heb je geen enkel probleem om over te schakelen op een andere database, MAAR als je applicatie is geschreven met een specifieke database als back-end zal het echt niet meevallen om dat zonder problemen om te schrijven naar een andere database, dat lukt je echt niet in een dagje zoals hierboven wel aangegeven wordt.

Natuurlijk functioneert SQL-server beter wanneer je met 15 gebruikers in een forse database zit. Het gaat er in dit geval alleen om dat Access het ook aan zou moeten kunnen en dat SQL-server roepen wel heel erg makkelijk is. Ik rijd ook liever in een Bentley, maar met mijn Golfje kom ik ook wel op de plaats van bestemming hoor.

[Verwijderd]

Zoals ik uit al het bovenstaande begrijp MOET Access kunnen voldoen!

Nog enige toelichting:

De applicatie wordt gebruikt om productiefouten te loggen, en over bepaalde periodes doorsnedes en analyses te kunnen maken.

Er worden deelassemblages en totaalassemblages geproduceerd. voor deze moeten apart de fouten ingevoerd worden.

Ook is er nog een reparatieprocedure, en de fouten hiervoor moeten ook ingevoerd worden.

Wat in de frond-end gedaan wordt (Whoami) is dat de reparatiefouten bij de productiefouten opgeteld worden. Hier worden vervolgens de analyses op uitgevoerd. Als dit mbv een query zou gebeuren (naar back-end) vereist dit meer (reken)capaciteit van het netwerk en de back-end.

Waarom wordt dit dan niet eenmaal per dag gedaan en wordt deze data naar een andere back-end weggeschreven oid???

Als er nieuwe data ingevoerd is moet deze direct bekeken kunnen worden. Dit maakt het nodig om de data op dat moment te updaten (bij opstarten analyses)