In mijn agenda scriptje heb ik een mogelijkheid om records nadien aan te passen.
Het script plaatst alle waarden terug in aparte invoervelden van het forfmulier.
Voorheen werkte ik met twee aparte databasevelden (date en time)voor datum en tijd waarbij de code om de gegevens uit de database te halen de volgende waren:
Op aanraden van jullie ben ik overgestapt naar een datetime veld waar dus de datum en de tijd samen staan opgeslagen, maar ik krijg het nu niet meer netjes uit de database in de juiste invoervelden van het formulier waarbij opgemerkt dat het db veld "datum" heet en nog steeds row1 is.
Kan iemand mij vertellen hoe het wel moet, met googelen kom ik er niet uit.
De datum en de tijd zijn nu d.m.v. de oplossing van Blanch mooi opgesplitst en staan terug in de invoervelden van het aanpas-formulier.
In kolom2 (nacht) staat bijvoorbeeld "nacht zo/ma", maar komt nu niet meer tevoorschijn, heb ik geen fout gemaakt in mijn query?
En in kolom4 daar staan de rest van de ritgegevens zoal van-naar--naam-aantal pers- etc etc allemaal gesplitst met een -.
Hoe trek ik die string nu weer uit elkaar, eerst ging dat met:
list($van, $naar, $naam, $aantal, $bedrag, $telefoonnummer, $vluchtnummer, $opmerking) = explode('-', $row[4]);
maar dat werkt nu niet meer.
Ik hoor graag van je.
Je hebt een fout datamodel, al die gegevens horen in een apart veld. Lees een wat over normaliseren en dan zal je ook begrijpen waarom. NU is het nog redelijk eenvoudig te herstellen. als er straks duizenden rijen zijn kan dat veel meer werk zijn.
Kortom pas eerst je datamodel aan, dan heb je zulke problemen in ieder geval niet
Beste Klaasjan, als ik nu zoals jij voorsteld voor elke invoer een apart veld maak, is er dan een mogelijkheid om de data die nu in dat ene veld staat op te splitsen en in de nieuwe apaprte velden te transporteren?
Het kan met een query maar die word redelijk ingewikkeld. Misschien is het handiger om met PHP de tabel leeg te trekken, de variabelen te scheiden en daarna een INSERT query op een nieuwe tabel uit te voeren.
Peter lees eerst eens het een en ander over database design. Wat ik voorstel is in principe nog redelijk brak (1e normaalvorm)
Je gebruikt de db dan als een veredeld .xls bestand. Over het algemeen wordt aangenomen dat en goede database iig 3e normaalvorm heeft.
Het is op xich trouwens redelijk abstracte materie en hoever je wil gaan met normaliseren hangt ondermeer af van je eigen ambitieniveau.
Voordelen zijn ondermeer "een altijd uitbreidbare database".
