Técnicamente, lo que intentas hacer está bien orientado. La propuesta de Jurena es perfectamente funcional, pero para estar seguros habría que saber con certeza qué formato tienen esas fechas.
Me explico: El problema básico con STR_TO_DATE() es que si alguna fecha está mal escrita, o tiene alguna diferencia respecto a lo esperado, entonces dará NULL. Y uno de los problemas de usar VARCHAR para las fechas es precisamente que debes validar mucho las entradas para que no pongan basura.
Esto funciona bien:
Código MySQL:
Ver original+------------+
| FECHA |
+------------+
| 2010-10-20 |
+------------+
Si no se respeta el orden dd/mm/aaaa, anda mal:
Código MySQL:
Ver original+-------+
| FECHA |
+-------+
+-------+
1 row
in set, 1 warning
(0.00 sec
)
Y si uno o ambos separadores no son lo s correctos, tampoco funciona:
Código MySQL:
Ver original+-------+
| FECHA |
+-------+
+-------+
1 row
in set, 1 warning
(0.00 sec
)
+-------+
| FECHA |
+-------+
+-------+
1 row
in set, 1 warning
(0.00 sec
)
Como verás, es una función algo exigente...
Tus pruebas:
Está mal, porque en la primera parte estás convirtiendo la fecha actual en una cadena con el formato "dd/mm/aaa" y en la segunda creando un DATE de una cadena "dd/mm/aaa". O sea estás tranformando una pera e una manzana y una manzana en una pera...
¿Para qué haces la primera conversión? Con esto alcanzaba:
En todos los restantes casos hiciste lo mismo...
Tips:
1. Prueba con lo que te está diciendo Jurena.
2. Verifica si puedes modificar la tabla y usar un DATE o DATETIME en lugar de usar un tipo de columna totalmente incorrecto y problemático como VARCHAR para guardar fechas. Ahorrarás espacio en disco y tendrás menos problemas en las consultas basadas en tiempo.