Probleem met openen Access

Status
Niet open voor verdere reacties.

Waterman1970

Gebruiker
Lid geworden
9 apr 2018
Berichten
10
Beste iedereen,

Voor mijn werk heb ik een aantal jaren terug een database gemaakt en wordt zonder problemen in gebruik genomen door max. 5 gebruikers.

Tegenwoordig als ik die database probeer te openen, loopt het vast of het duurt erg lang voordat het is geladen.

Wie weet wat de oorzaak zou kunnen zijn?

Berent
 
Daar is, zonder de db te zien, weinig van te zeggen. Je geeft ook weinig informatie; zo zou een nieuwe versie (met niet-geconverteerde database) een probleem kunnen zijn, de grootte van de database kan een rol spelen, het al dan niet regelmatig comprimeren van de database speelt mee, of het probleem optreedt bij 1 (de eerste dus) gebruiker, of als er 5 mensen in werken, of de db met een frontend-backend werkt, of je de backend op een netwerk schijf hebt staan.... Kortom: er zijn nogal wat variabelen.
 
Beste Octafish,

Dank voor je reactie!

Database staat op netwerk, is (nog) niet gesplitst, bestandgrootte is 604 Mb (en groeit nog steeds) en wordt vooral gebruikt voor artikelbeheer waarbij ook plaatjes / foto's in PDF / JPG worden bijgehouden.
Database wordt dagelijks gecomprimeerd.

Ben zelf een overmatig voorzichtige persoon die twijfelt tussen wel of niet gesplitste database. Tenminste, ik ga er van uit dat de splitsing van de database een éénrichtingsverkeer is waarbij het terugdraaien niet meer mogelijk is.

Ik verneem graag van je hoe hiermee om te gaan.

Maar de eerste prioriteit is achterhalen wat de oorzaak zou kunnen zijn van trage opstarten van database.
 
Er vallen me wel een paar dingen op. Om te beginnen:
Database staat op netwerk, is (nog) niet gesplitst, bestandgrootte is 604 Mb (en groeit nog steeds) en wordt vooral gebruikt voor artikelbeheer waarbij ook plaatjes / foto's in PDF / JPG worden bijgehouden.
Dat riekt naar het in de database opslaan van afbeeldingen. Daar ben ik zelf een grote tegenstander van, omdat dat een db nooit sneller maakt, alleen langzamer. Mijn plaatjes staan dus altijd in een map bij de database. Werkt perfect.

Ben zelf een overmatig voorzichtige persoon die twijfelt tussen wel of niet gesplitste database. Tenminste, ik ga er van uit dat de splitsing van de database een éénrichtingsverkeer is waarbij het terugdraaien niet meer mogelijk is.
Hier geldt: terugdraaien is altijd mogelijk, splitsen is bloedje simpel. Tenminste: zoals ik het doe. Ik maak gewoon een kopie van de database, hernoem de een Database_BE en de ander Database_FE en dan is de helft van het werk al klaar. Een BE bevat namelijk alleen de tabellen (en hooguit wat onderhoudsqueries en/of formulieren) en de FE alle formulieren, queries en rapporten. In de FE gooi je dus alle tabellen weg, in de BE gooi je alle formulieren, rapporten etc. weg, behalve dus de onderhoudstools.

De FE heeft uiteraard tabellen nodig, en die koppel je door via <Externe gegevens>, knop <Access>, de tweede optie (Koppelen etc.) te gebruiken, naar de zojuist gemaakte Database_BE te bladeren en die te openen. Vervolgens selecteer je alle tabellen, en maakt het verhaal af. In beginsel werkt je BE dan prima als tabellenbak, en je FE prima als gebruikerstool. Wat ik zelf tegenwoordig dan doe, is die FE aan elke gebruiker geven, die krijgt dan dus een eigen database.

Terugzetten kan heel simpel, door (bij voorkeur een kopie) van de FE te maken, alle gekoppelde tabellen te verwijderen het het bovenstaande proces nog een keer te doen, maar nu met de eerste optie (Tabellen etc. importeren).
Omdat alle tabellen dezelfde namen houden, en dezelfde velden, verandert er eigenlijk dus niks aan de FE.
 
Beste Octafish,

Ten eerste
Het opslaan van de afbeeldingen gebeurt inderdaad via Toevoegen Bijlage waardoor een kopie van dat bestand (JPG of PDF) opgeslagen wordt. Ik meende dat deze manier van "archiveren" de beste is aangezien:
1. er sprake is van één op één relatie
2. op die manier eigenlijk een back-up wordt gecreëerd
3. dat er een mooie rapportage (dus met plaatje) wordt afgedrukt; trouwens dat is alleen mogelijk met een JPG-bestand.

Het klopt dat de database hierdoor wat betreft de grootte flink gaat toenemen (of eigenlijk al is toegenomen).
Als jij daar een grote tegenstander van bent, hoe zou jij het dan doen?

Ten tweede
Het terugdraaien van de splitsing is volgens jou dus heel simpel. Dan ga ik dat met een kopie van die database even in de praktijk uitproberen.

Ik hoor het graag van je hoe met de eerste punt omgesprongen moet worden.
 
Laten we je punten die je bij Ten eerste noemt eens nalopen.

1. Heeft er niets mee te maken; relaties leg je tussen tabellen en niet tussen velden in een tabel. Of je een plaatje in een tabel opslaat, of een tekstverwijzing naar dat plaatje maakt niets uit.
2. Een backup van plaatjes? Is dat nodig? Als de map (je hebt het over een netwerkschijf) in de backup routine van het bedrijf is opgenomen, héb je toch al backups?
3. Plaatjes kun je altijd op een rapport of formulier laten zien, ongeacht of je ze in de database opslaat of niet. Je kunt veel meer plaatjes laten zien dan alleen jpg; ook png, bmp en gif bijvoorbeeld.
 
Beste Octafish,

1. Duidelijk
2. Een kwestie van zekere voor het onzeker nemen; heb een keer crash meegemaakt..........
3. Hoe krijg ik het dan voor elkaar als er geen plaatjes in database wordt opgeslagen en je deze toch op formulier of rapport te zien wilt krijgen?
 
Ad 2: mij lijkt het dat je bedrijfsprocessen redelijk kunt afdekken tegen crashes. En af en toe een kopietje maken van de map met afbeeldingen, mocht je die echt veilig willen stellen, lijkt mij een stuk nuttiger als ze opslaan in een database. Bovendien is het risico daar vele malen groter, want als de db crasht, heb je helemaal niks meer...
Ad 3: het proces is simpel, je slaat dus geen afbeeldingen meer op, maar verwijzingen naar de bestanden. Dat houdt vermoedelijk in, als je per hoofdrecord meerdere afbeeldingen nodig hebt of op wilt slaan, dat je daar een aparte gekoppelde tabel voor moet maken. Gat het nooit om meer dan één afbeelding per record, dan is een gewoon tekstveld afdoende.
Op het formulier/rapport maak je dan grafische objecten (afbeeldingsobject) aan, die geen foto krijgen toegewezen. Bij het laden/bladeren op het formulier wordt dan de actuele afbeeldingsnaam (eventueel +pad) uit de tabel gehaald, en aan het afbeeldingsobject toegewezen. Vervolgens zie je die afbeelding dan op je formulier of rapport. Gaat het om meerdere foto's, dan zul je het beste met een rapport/subrapport kunnen werken waarbij het subrapport dan in kolommen kan worden ingedeeld om meerdere foto's naast elkaar weer te geven. Op een formulier is dat wat lastiger, maar je kunt wel een doorlopend formulier met foto's op een hoofdformulier zetten.
 
Even voor de duidelijkheid over interpretatie "verwijzingen"; ik zie namelijk 2 mogelijkheden:

1. Gebruik maken van hyperlink of
2. Zoals je eerder beschrijft, een apart veld creëren voor naam van het bestand en in een nieuwe tabel een veld voor standaardlocatie op het netwerk. Bij het plaatsen van een object een combinatie van die twee en voilà?
 
Optie 1 is (althans voor mij) een groto NoGo. Als ik ergens een hekel aan heb, is dat het hyperlink veld. Optie 2 snap ik niet, zoals jij hem beschrijft. Ik zie net als jij twee mogelijkheden, maar dan wel andere. Namelijk deze:
1. Alleen de bestandsnaam van de foto
2. De volledige verwijzing, dus het complete pad (eventueel terug te vertalen naar het unc pad) + de naam van de foto.

De eerste optie gaat er vanuit dat alle foto's op een herleidbare plek staan. Ik gebruik voor een klant bijvoorbeeld de volgende constructie
- In de map waar de backend staat, heb ik een map <Afbeeldingen> gemaakt
- Voor elke nieuwe cliënt wordt in de map <Afbeeldingen> een map gemaakt op basis van het ClientID
- Voor elk nieuw dossier wordt in de map <Afbeeldingen\ClientID> een map gemaakt op basis van het DossierID
De mappen worden automatisch aangemaakt, dus de gebruikers hebben daar geen omkijken naar. Omdat de startlocatie van de map <Afbeeldingen> bekend is (CurrentProject.Path) en de rest van de paden is te herleiden uit de cliëntgegevens, hoef ik alleen een bestandsnaam voor de foto's en scans in te voeren. Ik maak ook altijd een kopie van de te plaatsen bestanden, zodat de oorspronkelijke foto's en scans gewoon blijven bestaan. Bijkomend voordeel: als de hele handel wordt verplaatst naar een andere (netwerk) locatie, blijft alles gewoon werken; er hoeft niets te worden aangepast.

Andere oplossing: als de startlocatie bekend is, kun je die makkelijk in de opstartroutine van de database in een TempVar variabele vastleggen. Daar is dus geen losse tabel voor nodig. Nadeel is dat bij verplaatsen van de database de tempvar moet worden aangepast, maar dat is een paar seconden werk.

Optie 2 gebruik ik alleen als de afbeeldingen niet mogen worden opgeslagen in een andere map en je dus een wildgroei aan verwijzingen krijgt. In dat geval is het noodzakelijk om het complete pad op te slaan. Dat maakt de tekststring doorgaans wat langer, maar dat maakt doorgaans niet zoveel uit.
Waarom geen Hyperlinkveld? Omdat je de actie FollowHyperlink aan een tekstveld kunt koppelen. Daarmee kun je dus, bijvoorbeeld bij een dubbelkik, altijd het bestand openen. Ik combineer dat doorgaans met een check op het tekstveld. Is dat veld leeg dan valt er niks te klikken, en kom je in de routine terecht waarmee je een bestand kunt opzoeken en plaatsen. Is het veld niet leeg, maar kan het bestand op basis van de gegevens niet worden gevonden (iemand heeft de foto verplaatst of hernoemd bijvoorbeeld) dan kom je ook in die routine terecht.
 
Beste Octafish,

In Access ben ik hier en daar bekend met WYSIWYG; gewoon kopiëren en plakken en vervolgens op inhoudelijke manier de velden vullen (uiteraard wel eerst goed over nadenken over hoe je Access wilt gaan gebruiken).
Ook al na een paar jaar te zijn achter gekomen: "Gossie, had eigenlijk op een andere manier gemoeten of gekund.................".
Van VBA heb ik geen kaas van gegeten.

Anyway, ik heb geworsteld met de door jou aanbevolen suggesties, maar de eindstreep zie ik nog niet.

Straks ga ik een kopie van die database maken en een bewerkte versie hier op deze forum zetten.

Waterman
 
Hierbij een heel erg bewerkt bestandje (oftewel vrij simpel, zonder inbreuk te doen op mijn werkgever).

Mijn opmerking staat in het formulier "Artikel_Beheer".

Bekijk bijlage Voorbeeldje.zip

De originele database is 600 Mb groot en ik heb al in een kopie van de database de bijlagen verwijderd en het blijkt dat het de helft van de grootte scheelt.

Waterman
 
600Mb is ook niet niks voor een Access database, die niet groter dan 2GB kan zijn. Dus je bent al over de 25% qua maximale grootte. Echt geen goed idee, plaatjes in de database opslaan. Ik kijk morgen wel even naar je db.
 
Jazekers, en hier een voorbeeldje met hoe ik het zou doen. Zoals je kunt zien, heb ik jouw db behoorlijk op de schop genomen. Om te beginnen: alle keuzelijsten in de tabellen omgezet naar tekstvelden (never nooit keuzelijsten in een tabel). Daarnaast de berekende velden eruit geknikkerd (never nooit berekende velden in een tabel). Verder de foto's in dezelfde map (met submappen) gezet als database, zodat de hele handel zonder probleem verplaatst kan worden naar een andere locatie zonder problemen.
Kortom: dit bestand zou je alleen hoeven uit te pakken op een door jou te bepalen locatie, en dan zou hij gelijk goed moeten werken.
 

Bijlagen

  • Voorbeeldje_v2.zip
    1,6 MB · Weergaven: 52
Status
Niet open voor verdere reacties.
Steun Ons

Nieuwste berichten

Terug
Bovenaan Onderaan