gekoppelde foto's van plaats veranderd

Status
Niet open voor verdere reacties.
Ik heb even naar de db gekeken, en ik zie dat mijn code daar niet werkt. In mijn eigen voorbeeld dus wel. Ik kijk morgen wel even naar de reden waarom het bij jou niet werkt.
 
Kan gebeuren :).
Er zit iets vreemds in de db van Els, want ik heb de tabel met grafgegevens naar een nieuwe db gekopieerd en daar de query gedraaid, zonder problemen. Mijn definitieve oplossing is dus deze:
Code: 
UPDATE grafgegevens SET 
foto1 = IIf([foto1] Is Null,Null,Mid([foto1],InStrRev([foto1],"\")+1,Len([foto1]))), 
foto2 = IIf([foto2] Is Null,Null,Mid([foto2],InStrRev([foto2],"\")+1,Len([foto2]))),
foto3 = IIf([foto3] Is Null,Null,Mid([foto3],InStrRev([foto3],"\")+1,Len([foto3]))), 
foto4 = IIf([foto4] Is Null,Null,Mid([foto4],InStrRev([foto4],"\")+1,Len([foto4])));

Hierbij haal ik dus de complete padnaam weg. De reden daarvoor heb ik al eerder uitgelegd: die zou ik in een TempVAR variabele zetten. Bij het inlezen van de foto's in rapporten en formulieren gebruik je dan de tempvar als plaatsaanduiding. Mocht je de database nog een keer willen verplaatsen, dan verander je één keer die TempVar en dan ben je klaar. Bovendien is het veel makkelijker om de fotovelden te vullen vanuit een Filebrowser object, want daarmee lees je alleen de bestandsnaam in. En meer heb je ook niet nodig. Dus wég met dat pad!

En als laatste opmerking: haal die foto's inderdaad weg uit de tabel Grafgegevens, want ze horen in een aparte tabel te staan. Je gebruikt die tabel verkeerd.
 
Elsverheyen zei:
Ik doe waarschijnlijk iets fout want hij vindt de tabel niet nochtans heb ik de naam aangepast
UPDATE tblgrafgegevens SET
Klik om te vergroten...
De tabel heet "grafgegevens". Als je dat wijzigt werkt de query wel.
Nog een kleine tip: neem "foto5" ook mee, want er zijn records waar dat veld ook is ingevuld.
 
Oeps, ik vergeet de correctie vanwege het wijzigen van Null in "". De regels moeten zijn
SQL: 
foto1 = IIf([foto1] Is Null,Null,"F:\afbeeldingen\kerkhof Ramsdonk\" & Mid([foto1],InStrRev([foto1],"\")+1,Len([foto1])))
etcetera.
 
Nog een (veel) betere tip, óók van Peter: haal de foto’s uit deze tabel en sla alle foto’s op in een aparte tabel. Niet alleen klopt je tabel dan weer, je bent ook af van het maximum van 6 foto’s, mocht je daar behoefte aan hebben. Maar stop zo snel mogelijk met het opslaan van foto’s in deze tabel. En stop dus óók met het opslaan van het volledige pad in de fotonamen!

Mocht je er tegen in willen werpen dat je dan ook je formulieren moet aanpassen, en dat dat dan extra werk is: dat klopt. Zie het als een (dure, tijdrovende, nuttige, noodzakelijke (kies zelf maar een variant) les, namelijk deze: nooit formulieren maken als de database niet helemaal in orde is. En die van jou is dat dus (nog) niet. Zorg er eerst voor dat je alle tabellen (genormaliseerd) in orde hebt voordat je formulieren gaat maken.
 
Een applicatie is nooit helemaal in orde. Een bedrijf is een levend iets dat groeit en verandert, dus ook de custom applicaties zullen moeten meegroeien/aanpassen. Er zijn veranderende inzichten, men leert bij, de basissoftware krijgt updates en meer mogelijkheden. Daarom is men al lang afgestapt van het idee om eerst alles dood te analyseren, dan de structuren vast te leggen en dan de UI te maken. Men creëert eerst een basismodule met de inzichten van dat moment zodat men de applicatie snel kan gebruiken. Op dat moment ziet men ook veel duidelijker wat men nodig heeft/wenst. En ja, dan moet men wel eens bestaande database en UI objecten aanpassen. That's life ;)
 
We hebben het hier over een vrij simpele database waarvan de grondbeginselen niet deugen. Dat moet eerst in orde worden gemaakt. Dat is iets totaal anders dan ‘meegroeien’ met de organisatie, en dat heeft niets te maken met ‘dood analyseren’.
 
I disagree, men begint met wat men kent en past het later aan als men meer weet, zo leer je en dat is iets dat jij heel hoog in het vaandel houdt.
 
OctaFish zei:
Zorg er eerst voor dat je alle tabellen (genormaliseerd) in orde hebt voordat je formulieren gaat maken.
Klik om te vergroten...
Helemaal mee eens.

NoellaG zei:
men begint met wat men kent en past het later aan als men meer weet
Klik om te vergroten...
In dit geval is duidelijk dat zaken niet kloppen, daar hoef je niet eerst meer van te weten.


Als "we" de boel dan toch grondig gaan verbouwen, weet ik er ook nog wel een paar :D
  • De vorm van begraven zou ik anders opzetten. Maak er een (op het formulier) een keuzevak-met-invoervak van en zet de toegestane waardes in een tabel. Maak de looptijd en prijs velden in die tabel. Je bent zo flexibeler bij wijzigingen (prijzen, andere vormen).
  • Hetzelfde zou ik doen met de keuzerondjes die er op het scherm naast staan. Dat zijn nu allemaal ja/nee-velden. Volgens mij zouden de opties elkaar moeten uitsluiten (dus één veld), maar nu is het mogelijk ze allemaal te kiezen. Overigens is me sowieso niet duidelijk wat het verschil tussen deze reeks velden en de vorm van begraven is. Zo op oog lijken me dat ook vormen van begraven.
  • Bij concessie startdatum en concessie einddatum proef ik overlap c.q. mogelijke inconsistentie met de duur die staat bij de vorm van begraven. Als je startdatum kent en de vorm van begraven, is de einddatum af te leiden.
  • En als klap op de vuurpijl: ik zou één tabel voor personen maken (plus een relatietabel en een tabel voor de soorten relaties). Één en dezelfde persoon kan in meerdere hoedanigheden voorkomen. Bijvoorbeeld een kind van een begraven persoon kan zelf ook begraven zijn. Een contactpersoon van de ene begraven persoon kan net zo goed een verwante zijn van een andere. Je wilt de gegevens van elke persoon maar één keer vast hoeven te leggen. Het onderscheid maken tussen verwantschappen van mannen en van vrouwen is al helemaal niet van deze tijd. Partners van hetzelfde geslacht zijn geen uitzondering.
 
Ik stel voor dat we het getheoretiseer even in de la laten liggen en ons concentreren op de eigenlijke vraag van Els. Die is ondertussen wel beantwoord denk ik, en zolang zij niet aangeeft dat ze de opzet wil aanpassen en daarbij hulp nodig heeft (ik zou daar dan een nieuwe vraag voor aanmaken) heeft elke overige discussie geen zin. Als ik wil debatteren, ga ik wel in de tweede kamer zitten :).
 
Mannekes, geen ruzie maken.
Ik heb misschien 20 jaar geleden een kleine cursus gevolgd van access en probeer hier mijn plan mee te trekken om een kleine database te maken en aan te passen aan mijn noden en over de jaren heb er een aantal zaken aan toegevoegd. Ondertussen is deze database toegevoegd aan een veel grotere die door een professional is ontworpen. Voor wie interesse heeft zie op onze website http://erfgoedcel.kapelle-op-den-bos.be/ onder zoeken. Maar ik gebruik de mijne nog verder als basis.
Dus voor wie mij wil helpen al vast nog eens bedankt. Ik moet de volgende dagen werken en kan ik niet verder proberen of het mij lukt om de dingen aan te passen, dus even geduld.
 
Altijd, dat weet je toch?
 
Hey,
heb de code geprobeerd en het werkt maar het zou één map meer moeten laten staan.
\Kerkhof Nieuwenrode D1\Nieuwenr 1 - 5.jpg want dat wisselt van D1 tot D6
kan dat?
Al neig bedankt.
Els
moet niet in vetgedrukt natuurlijk
 
Nogmaals: sla géén onderdelen van je pad op! Het is voldoende om alleen de naam van de foto op te slaan, en het pad via één van de aangegeven methodes (mijn voorkeur: TempVar variabele) op te slaan en te gebruiken.
Overigens heb je het nu over zes verschillende basismappen, niet meer over één map. Dat maakt uiteraard nog wel wat uit. In dat geval zou ik toch ook de Replace methode van #2 gebruiken, omdat je dan ook een deel van de string mee kan nemen. Zelf zou ik de deellocatie uit de naam (en padnaam) halen en die informatie apart opslaan in de tabel. Het lijkt mij nogal relevante informatie over het graf. Hoort m.i. dus niet thuis in de fotonaam, maar in het record.
 
Ik ben even de draad kwijt.
Zijn er nu zowel in de oude situatie als in de nieuwe situatie 6 mappen? Of..........?

En wat is nu het nieuwe pad?
"F:\afbeeldingen\kerkhof Ramsdonk\Kerkhof Nieuwerode Dx\"??

En heeft het feit dat je in je tabel foto1 tot en met foto6 hebt iets te maken met het feit dat je over 6 mappen spreekt?
 
Tja, de zaak wordt er niet makkelijker op :). Maar je query ziet er dan zo uit:
Code: 
UPDATE grafgegevens SET foto1 = Replace([Foto1],"D:\Els Verheyen\Pictures\Erfgoed\kerkhof Nieuwenrode\",
"F:\afbeeldingen\kerkhof Ramsdonk\")
WHERE [foto1]) Is Not Null;
En dat dan voor elk veld. Ach, hoe vaak moeten we nog zeggen dat deze structuur niet deugt? Dit moet je écht niet willen!
 
Status
Niet open voor verdere reacties.
                    Steun ons                    

Nieuwste berichten

Terug
Bovenaan Onderaan