sorteren van een niet datum veld... nieuw issue

Niet direct het antwoord, maar wellicht voor de toekomst om de datum om te zetten.

# selecteren van datum
SELECT
	ENDDATE,
	SUBSTRING_INDEX( ENDDATE, '-', -1 ) AS jaar,
	LPAD(SUBSTRING_INDEX( SUBSTRING_INDEX( ENDDATE, '-', -2) , '-' , 1), 2, '0') AS maand,
	LPAD(SUBSTRING_INDEX( ENDDATE, '-', 1 ), 2, '0') AS dag,
	CONCAT(
		SUBSTRING_INDEX( ENDDATE, '-', -1 ),
		'-',
		LPAD(SUBSTRING_INDEX( SUBSTRING_INDEX( ENDDATE, '-', -2) , '-' , 1), 2, '0'),
		'-',
		LPAD(SUBSTRING_INDEX( ENDDATE, '-', 1 ), 2, '0')) AS nieuwjaar
FROM
	person;

# update van datum
UPDATE
	person
SET
	ENDDATE = CONCAT(
		SUBSTRING_INDEX( ENDDATE, '-', -1 ),
		'-',
		LPAD(SUBSTRING_INDEX( SUBSTRING_INDEX( ENDDATE, '-', -2), '-' , 1), 2, '0'),
		'-',
		LPAD(SUBSTRING_INDEX( ENDDATE, '-', 1 ), 2, '0')
		);

> Of dat slim is kunnen we over hebben.. maar het is nu eenmaal een gegeven. Zou mijn keus niet zijn geweest.

Als je het kunt repareren zou je het moeten repareren, nu ben je alleen maar werk voor je uit aan het schuiven.

Thomas van den Heuvel op 23/02/2019 01:05:33

> Of dat slim is kunnen we over hebben.. maar het is nu eenmaal een gegeven. Zou mijn keus niet zijn geweest.

Als je het kunt repareren zou je het moeten repareren, nu ben je alleen maar werk voor je uit aan het schuiven.

@Thomas, I know.... maar helaas ik heb er mee te dealen. Als ik het in eigenhand zou hebben dan zou ik je advies meteen ter harte nemen....

Onderstaande conversies lukken bij mij wel

Jan

SELECT
SUBSTRING_INDEX(textdate, '/', 1),
SUBSTRING_INDEX(SUBSTRING_INDEX(textdate, '/', 2),'/',-1) ,
SUBSTRING_INDEX(textdate, '/', -1) ,
STR_TO_DATE(
CONCAT(
SUBSTRING_INDEX(textdate, '/', -1),'-',
LPAD(SUBSTRING_INDEX(SUBSTRING_INDEX(textdate, '/', 2),'/',-1) ,2,'00'),'-',
LPAD(SUBSTRING_INDEX(textdate, '/', 1),2,'00')),
'%Y-%m-%d') converteddate,
textdate,
gooddate ,

STR_TO_DATE(textdate, "%e/%c/%Y") converted_date
FROM
`test`

Dit:
> mysqli_num_rows() expects parameter 1 ???
is trouwens maar een halve foutmelding.

Wanneer een query syntactisch niet goed is levert een aanroep voor het uitvoeren doorgaans false op. Nog voordat je dingen met het resultaat doet of probeert te doen (num_rows, fetch_whatever) is het zaak dat je eerst controleert of de query is geslaagd. Als hier geen sprake van is kun je alle vervolgacties rustig staken.

Ik zou je (toch) nogmaals het advies willen geven om de databasestructuur op orde te maken, want nu ben je enkel bezig met symptoombestrijding. Dit is eigenlijk de enige juiste oplossing.

Indien deze database niet in jouw beheer is zou je de eigenaar kunnen vragen om de datumkolommen te converteren. Of, wanneer dit om backwards compatible redenen niet mogelijk is (meerdere partijen hebben oplossingen lopen breien om dit slecht ontwerp tegemoet te komen) zou je een nieuwe kolom kunnen (laten) aanmaken die wel een zinnig datumformaat heeft waarmee je kunt rekenen.

Nogmaals, elke andere oplossing is tot op zekere hoogte onzinnig omdat je allerlei doekjes voor het bloeden introduceert.

Het idee van een database is ook dat je hier makkelijk informatie uit zou moeten kunnen halen. Wanneer dit niet lukt dan is er simpelweg iets mis met het ontwerp.

Je kunt hier of een heleboel (overbodig) programmeerwerk tegenaan gooien, of het gewoon op de juiste plek oplossen.

Misschien in de ORDER BY sorteren met de MySQL str_to_date function??

SELECT 
.
.
.
.
ORDER BY str_to_date(ENDDATE,'%Y-%m-%d');

waarbij je het format %Y-%m-%d nog wel even in het door jou gebruikte model moet zetten en eventueel foute data in een case structuur wegselecteren om MySQL foutmeldingen te voorkomen.

@Aad... thnkx.. dit is voor nu iets dat werkt. thnx

@Thomas.. ik kan je niet anders dan gelijk geven. Maar meer dan dit gegeven zit er toch echt niet in. Ben het met je eens dat de opbouw op deze manier belabberd is en dat je dan achter de feiten aanloopt door allerlei houtje-touwtje oplossing en veel corretiewerk te doen.. Maar het is uitgesloten dat ze de database aanpassen, Heb ik er al meerdere malen om verzocht.. zonder resultaat

@alle andere.. bedankt weer voor het meedenken.