FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
|
#1
|
|||
|
|||
Cita:
|
#2
|
||||
|
||||
Gracias beginner01, juraría que no me aceptó algo así hace tiempo cuando tuve oportunidad de manejar MS-SQL.
Me salta la duda de si no estará convirtiendo lo que devuelve GETDATE() a cadena. Es decir, ¿realmente está haciendo una comparación de fechas o más bien es una comparación de cadenas de caracteres? |
#3
|
|||
|
|||
Cita:
Para comprobarlo ya que no aparece o no encontré suficiente documentación sobre esto realicé una prueba para ver el que ocurre y al hacer algo como esto. Colocando la hora en un formato incorrecto (14T25:04:50) devuelve este error "The conversion of a varchar data type to a datetime data type resulted in an out-of-range value." con lo cual me queda claro que SQL Server convierte la fecha literal a datetime para luego hacer la comparación. Las pruebas fueron realizadas en SQL Server 2000 y 2008. |
#4
|
||||
|
||||
Muchas gracias, beginner01.
¿Renombramos la función ghISODateTime por ghSQLDateTime? |
#5
|
||||
|
||||
Cita:
Un saludo |
#6
|
||||
|
||||
Bien, pero entonces creo que mejor sería contar con funciones para ambos tipos de formato:
1. ISO, con la famosa "T" entre la fecha y la hora, e invariable. 2. SQL, sin la "T", pero "configurable" mediante variable global, dado el frágil consenso que hay entre los distintos fabricantes. Y aquellas otras funciones relacionadas con SQL que necesiten convertir una fecha y hora a expresión literal usarían la opción #2. El programador, entonces, dependiendo del motor que use y la configuración de éste, ajustaría la variable global de formato según se requiera. Aunque, de entrada, el valor predeterminado de dicha variable sería 'yyyy-mm-dd hh:nn:ss' ("nn" es para minutos en Delphi), por ser el formato que todos los motores "deberían" aceptar incondicionalmente. Veo que se respondió muy poco a las preguntas que he hecho a lo largo del hilo. ¿Tan aburrida es esta sección? |
#7
|
||||
|
||||
Cita:
Lo que estas pensando no tiene sentido. O mejor dicho, es una aberración (y demuestra porque nombrar cosas es una de las dos cosas mas dificiles). Dices que quieres tener una funcion que devuelve la fecha en estandar ISO. Eso solo tiene un sentido: Devuelve una cadena en estándar ISO y eso es todo. Luego, resulta que por la razon que sea, X sistema tiene algo que se parece al estándar ISO. Entonces deberías mandarle la cadena que SI ES el estándar ISO? NO! Porque no lo es. Y deberías "configurar" la función para que devuelva algo parecido al ISO? NO. Porque la función dice que se llama "devolver cadena estándar ISO". Es algo muy preciso. -- Eso lo tienes claro. Solo recalco. Y tener una función que formatea de forma diferente de acuerdo a como lo diga el programador, se llama "Format Date". Que tiene un carajo que ver con que sea el ISO. Asi que al punto al que voy es que los nombres deben ser precisos en su intención. "FormatDateAsISO" es un nombre preciso. "FormatDate(FormatString:String)" tambien (denota que es ambiguo y se configura con FormatString). "FormatDateAsFirebird" es algo preciso. La patada es hacer algo como "FormatDateAsSql" -esta es la aberracion a la que hablo- porque resulta que eso depende de cada motor, pero da la idea que me formatea correctamente como "sql" lo cual, en si, es una suposición *erronea*. Entonces para corregirla tocaria hacer algo como "FormatDateAsSql(Engine:TDBEngine)" y no se si quieres ponerte a hacer la implementacion pa cada motor. Pero es aun peor. Resulta que muchos programadores (que de por si, al mandar fechas como cadenas ya es un error) mandan la fecha de acuerdo al "locale" de sistema operativo (que puede diferir del de la BD)... son como 3 "locales" diferentes en juego: Lo que dice tu funcion, lo que dice el OS, lo que dice la BD (ah, y lo que cree el programador, que no ha pensado en esto). Lo correcto, como creador de libreria, es dar solo funciones *precisas* y funciones configurables -pero desligadas, osea, agnosticas-, pero cuidarse de interpretar las intenciones y entornos donde operan. Si el programador X maneja un motor Y, en un "locale" Z y necesita una cadena formateada, es EL el que debe crear "FormatDateForDBX", no la libreria (a menos que, sea la libreria "DBXLibrary", osea, sea para ese motor en especifico - si es que el engine tiene un formato "fijo" independiente del locale). Y usar una vble global es un error (las vbles globales son en el 99.99% de los casos un error de diseño).
__________________
El malabarista. |
|
|
Temas Similares | ||||
Tema | Autor | Foro | Respuestas | Último mensaje |
Ayuda sobre manejo de fechas | francodelphi | Conexión con bases de datos | 12 | 27-10-2011 01:22:15 |
Como definir Funciones Globales | destrukthor | Varios | 4 | 07-07-2006 14:12:18 |
Problemas al definir UDF (Funciones en una DLL) | pcicom | Firebird e Interbase | 2 | 21-06-2006 05:49:15 |
Definir funciones y procedimientos en FastReport???? | burasu | Impresión | 1 | 16-05-2005 21:47:37 |
Sobre actualizaciones de programas y estándar x2 | obiwuan | Humor | 0 | 06-05-2003 22:04:07 |
|