Update SQL werkt niet
$sql="UPDATE users SET a2=$a2, a5=$a5, a15=$a15, a16=$a16, a17=$a17, a18=$a18, a19=$a19, a20=$a20, a21=$a21 WHERE ID=$ID";
Echter wanneer ik meer dan 9 aanpassingen in 1x wil uitvoeren, voorbeeld:
$sql="UPDATE users SET a2=$a2, a5=$a5, a15=$a15, a16=$a16, a17=$a17, a18=$a18, a19=$a19, a20=$a20, a21=$a21, a23=$a23 WHERE ID=$ID";
Dan doet ie het niet meer.
Is hier een oplossing voor?
Alvast heel erg bedankt :-)
Gewijzigd op 22/09/2014 13:35:55 door Sander HTC
Verdiep je eens in Database-normalisatie: http://nl.wikipedia.org/wiki/Databasenormalisatie
Gewijzigd op 22/09/2014 13:49:18 door - Ariën -
- SanThe - op 22/09/2014 13:40:37:
Bouw foutafhandeling in en zie de foutmelding.
Ja, dan krijg ik: Unknown column 'voorbeeld' in 'field list'
Met $a2 als voorbeeld
Uiteraard heb ik een mijn database een colum genaamd a2, dit heb ik al gecontroleerd
Gewijzigd op 22/09/2014 13:51:21 door - Ariën -
- Aar - op 22/09/2014 13:47:15:
En wat is de reden dat je genummerde velden hebt? Met SQL wil je juist goed schaalbare queries maken, zonder regelmatig een veld toe te moeten voegen uit een bepaalde entiteit (groepen op een school bijv.)
Verdiep je eens in Database-normalisatie: http://nl.wikipedia.org/wiki/Databasenormalisatie
Verdiep je eens in Database-normalisatie: http://nl.wikipedia.org/wiki/Databasenormalisatie
Ik werk met genummerde velden:
1: Omdat ik het makkelijker vind om nummers te onthouden dan woorden, dus ik heb liever
a1, a2, a3, a4 dan profielnaam, plaats, wachtwoord, etc
2: Ik wil geen woorden in mijn script, omdat mijn scripts alle woorden uit de pagina haalt van de taal van de bezoeker en zo houd ik het overzichtelijk (voor mezelf)
:-)
Toevoeging op 22/09/2014 13:55:44:
- Aar - op 22/09/2014 13:50:54:
Wat staat er in $a2?
Momenteel is $a2:
$a2 = "voorbeeld";
En dan werkt ie nog steeds niet
en a2 in mijn databse is:
a2 varchar(100) latin1_swedish_ci
Tevens kan je met een genormaliseerde database makkelijker berekeningen uitvoeren dan met een ongenormaliseeerde database.
Dus misschien is het toch eens de moeite om ernaar te kijken. We willen je graag helpen met de opzet van een dergelijke database als je er niet uit komt. Ik kan je verzekeren dat alles op die manier juist een stuk overzichtelijker zal worden dan nu.
Kort samengevat: Genummerde velden zijn not-done, als je het omzet naar records, dan is het well-done ;-)
Als je kan vertellen wat je precies wilt bereiken met het systeem wat je bouwt, dan kunnen we meer vertellen.
Gewijzigd op 22/09/2014 14:02:04 door - Ariën -
$sql="UPDATE users SET a2='$a2', a5=$a5, a15=$a15, a16=$a16, a17=$a17, a18=$a18, a19=$a19, a20=$a20, a21=$a21, a23=$a23 WHERE ID=$ID";
:-)
Gewijzigd op 22/09/2014 14:04:37 door - Ariën -
Pipo Clown op 22/09/2014 14:12:39:
Ik neem aan dat de mogelijkheid dat je database gehacked wordt via SQL-injection dan ook bewust open gehouden is omdat je dit gemakkelijker en overzichtelijker vindt ?
Als we sarcastisch gaan doen: ja natuurlijk, zijn toch niet mijn gegevens!
Blijft alleen jammer dat ik weinig hoor over mijn goed bedoelde advies.
Gewijzigd op 22/09/2014 14:40:13 door - Ariën -
- Aar - op 22/09/2014 14:38:14:
Wat heeft dit met sarcasme te maken? Het is gewoon een normale vraag.
Blijft alleen jammer dat ik weinig hoor over mijn goed bedoelde advies.
Blijft alleen jammer dat ik weinig hoor over mijn goed bedoelde advies.
Beste Aar, bedankt voor je ongevraagd advies wat me niet heeft geholpen :-)
Niet rottig bedoeld, maar als je doorgaat op de manier die je nu nog hanteert, dan kan je behoorlijk 'op hete kolen lopen' en tegen diverse knelpunten aanlopen. Je moet echt zelf weten. Het loont in ieder geval om er eens naar te kijken. Ik zeg niet dat je het binnen nu en dan moet aanpassen.
Vergeet niet dat er op dit forum ook gevorderden en experts zitten die mensen graag ook advies willen geven voor betere methodes, en men erbij kunnen helpen. Het zou in ieder geval fijn zijn als diegene er open voor zou staan in plaats van het direct af te wijzen zonder te zeggen waarom.
Gewijzigd op 22/09/2014 15:44:05 door - Ariën -
Met wegnummer N207 weet lang niet iedereen waar deze ergens ligt maar met 'De weg van Hillegom tot Gouda' zullen veel mensen al een gevoel krijgen waar ze moeten gaan zoeken op de kaart.
Jouw mening slaat dus helemaal nergens op.
Sander HTC op 22/09/2014 14:35:31:
Als we sarcastisch gaan doen: ja natuurlijk, zijn toch niet mijn gegevens!
Pipo Clown op 22/09/2014 14:12:39:
Ik neem aan dat de mogelijkheid dat je database gehacked wordt via SQL-injection dan ook bewust open gehouden is omdat je dit gemakkelijker en overzichtelijker vindt ?
Als we sarcastisch gaan doen: ja natuurlijk, zijn toch niet mijn gegevens!
Jongens laten we het gezellig houden zo op de maandag middag.
Waar bijvoorbeeld 5 bij a19 staat voor:
Blauw (in het Nederlands)
Blue (in het Engels)
Blau (In het Duits)
etc.
Ergens anders in het script wordt 5 bij a19 gekoppeld met de juiste taal en woord
(die gebruiker/browser heeft gekozen)
In welk opzicht zou ik dit dan kunnen verbeteren?
Sorry voor mijn geïrriteerde antwoorden.
Gewijzigd op 22/09/2014 16:40:25 door Sander HTC
Elke kleur heeft een eigen record met een ID-nummer (auto increment). Verder is er ook een tabel kleuren_users. Deze heeft de velden ID en UserID, en legt de koppeling tussen de gebruiker en de kleur.
Ik heb nog geen precies idee wat de topicstarter als doel heeft, en wat het script volledig gezien moet doen, maar dit is al een sterk verbeterde opzet zoals nu.
Gewijzigd op 22/09/2014 17:44:51 door - Ariën -
- Aar - op 22/09/2014 17:40:12:
Ik zou een tabel maken met 'kleuren' (gaat het alleen om kleuren.
Elke kleur heeft een eigen record met een ID-nummer (auto increment). Verder is er ook een tabel kleuren_users. Deze heeft de velden ID en UserID, en legt de koppeling tussen de gebruiker en de kleur.
Ik heb nog geen precies idee wat de topicstarter als doel heeft, en wat het script volledig gezien moet doen, maar ik dit is al een sterk verbeterde opzet zoals nu.
Elke kleur heeft een eigen record met een ID-nummer (auto increment). Verder is er ook een tabel kleuren_users. Deze heeft de velden ID en UserID, en legt de koppeling tussen de gebruiker en de kleur.
Ik heb nog geen precies idee wat de topicstarter als doel heeft, en wat het script volledig gezien moet doen, maar ik dit is al een sterk verbeterde opzet zoals nu.
Nee Aar, elke kolom bevat andere gegevens en al deze gegevens worden niet meer gewijzigd of toegevoegd alleen maar geselecteerd en weergegeven.
Dus ik kan inderdaad een Databank maken van de gebruiker met in elke kolom een ID naar de andere databank met daarin dan het nummer wat het script moet hebben. Maar dat lijkt mij omslachtiger dan wat ik nu heb, want dan krijg ik zo'n 40 databanken.
Of ik begrijp het helemaal verkeerd.
Waarom sla je die waardes dan niet op per record, in een kleuren tabel (of een 'waardes'-tabel).
Dan kan je zo onbeperkt veel records aanmaken voor de waardes, en deze koppelen aan de userID's.
Voordelen: Het is overzichtelijker, je hoeft de queries in je applicatie niet steeds aan te passen als er een nieuwe waarde bij moet komen.
Ik weet niet wat jij onder een databank verstaat, maar het gaat in dit geval om 1 database, met daarin drie tabellen:
- users
- kleuren (of waardes)
- kleuren_users / waardes_users
De tabel kleuren_users worden dan wel groot, maar dat maakt voor MySQL niet uit. Een paar integertjes met cijfertjes is echt niet zo veel, en MySQL kan heel veel slikken en opslaan.