consulta sobre fecha

Una campo no necesariamente tiene que contener un dato a menos que fue un
indice, a eso me voy cuando uno crea un campo asigna un default o aveces no,
y ese aveces no se convierte en null, y eso no me agrada mucho desde el vfp
controlo el null, el usuario no lo llega a ver
pero cuando abro la tabla parece una hoja con borrones, a eso me refiero.
asi como el campo numerico tienen su default 0, o el caracter su defalt es
'', el datemite o es el getdate() o el null
y getdate como default puede provocar confusiones si el dato es obviado (o
se coloca cualquiera para salir de cualquier restriccion) e inserta la fecha
actual, lo que me obliga a usar un campo adicional para controlar si es o no
el dato correcto...
y si le dejo null ya lo comente anteriormente asi que preferiria un valor
vacio a culquiera de las 2 anteriores.


"Carlos M. Calvelo" escribió en el mensaje de
noticias
news:
Hola Luis,

On 17 okt, 19:31, "Luis Mata"
wrote:

correcto pero yo no quiero que salga ninguna fecha, osea vacio el campo
esta
seteado para que no acepte null, y en lugar de dejarlo vacio inserta ese
valor 19000101 y eso es lo que no quiero porque se presta para
confusiones.
entienda que el campo se usa con fechas pero algunos registros se requiere
que quede vacio

Puedes explicar qué es lo que entiendes tu por 'campo vacío',
pero no nulo? Y por qué no puede ser nulo?
Puedes tratar de explicar también que regla es la que requiere que
'quede vacío'? O sea, qué significado tiene el 'estar vacío'?

Tienes tres opciones:

1) permitir que el campo sea nulo en los registros para los que se
'requiere' que ese campo quede 'vacío'.
2) utilizar un valor especial como 19000101 para señalar que no
hay fecha y no aceptar nulos. En ese case 19000101 no es posible
como fecha.
3) normalizar la tabla. Esto quiere decir que borras esa columna
y creas otra tabla con la misma clave primaria que la primera
tabla y con una columna con esa fecha. En esta segunda tabla
solo introduces aquellos registros para los que se tiene que
proporcionar una fecha. Pero va a tener como resultado que al
hacer un outer join de las dos tablas te apareceran otra vez
los nulos. Al hacer el join se pueden convertir los nulos a un
valor especial (como 19000101) pero estamos otra vez con el
el problema original (nulo o valor especial).

La última opción es interesante en el caso de que se espere que para
la gran mayoría de los registos la fecha va a quedar vacía.

Para todas las opciones puedes también al hacer una consulta,
convertir las fechas a tipo char o varchar e interpretar los
nulos o el valor especial como '' (cadena vacía). Pero entonces
la columna en el resultado ya no es datetime, sino char o varchar.

Mira este ejemplo (siguiendo con el de Alejandro) para ver como
puedes hacer esto último con los nulos o con el valor especial:

-
declare @t table (dt datetime NULL)

insert into @t default values
insert into @t values('')
insert into @t values(getdate())

select
dt,
case
when dt is null or dt = '19000101' then ''
else convert(varchar, dt, 121)
end as FechaChar
from @t
-

Vistas otras reacciones creo que aquí se están confundiendo los
nulos como marca de falta de información con la presentación
de ese hecho a los usuarios en las aplicaciones.
Este último ejemplo deja claro que los nulos no tienen ni por
que llegar a las aplicaciones (piensa en vistas), para cuanto
mas a la presentación a los usuarios.

Saludos,
Carlos

pero cuando abro la tabla parece una hoja con borrones, a eso me refiero.

Y eso es un problema? en la aplicación es que tienes que controlar su
despliegue.

Además una fecha vacía {//} como la usa VFP, en una verdadera base de datos
es un error ya que no es realmente una fecha. Debes cambiar esa concepción.
No veo ningún problema en que la dejes en NULL y ajustes el despliegue o
uses alguna de las otras opciones que te han dado.

prefiria en blanco

"Pedro" escribió en el mensaje de noticias
news:%

pero cuando abro la tabla parece una hoja con borrones, a eso me refiero.

Y eso es un problema? en la aplicación es que tienes que controlar su
despliegue.

Además una fecha vacía {//} como la usa VFP, en una verdadera base de
datos es un error ya que no es realmente una fecha. Debes cambiar esa
concepción.
No veo ningún problema en que la dejes en NULL y ajustes el despliegue o
uses alguna de las otras opciones que te han dado.

Hola Luis,

On 20 okt, 22:53, "Luis Mata"
wrote:

Una campo no necesariamente tiene que contener un dato a menos que fue un
indice, a eso me voy cuando uno crea un campo asigna un default o aveces no,
y ese aveces no se convierte en null, y eso no me agrada mucho desde el vfp
controlo el null, el usuario no lo llega a ver
pero cuando abro la tabla parece una hoja con borrones, a eso me refiero.
asi como el campo numerico tienen su default 0, o el caracter su defalt es
'', el datemite o es el getdate() o el null
y getdate como default puede provocar confusiones si el dato es obviado (o
se coloca cualquiera para salir de cualquier restriccion) e inserta la fecha
actual, lo que me obliga a usar un campo adicional para controlar si es o no
el dato correcto...
y si le dejo null ya lo comente anteriormente asi que preferiria un valor
vacio a culquiera de las 2 anteriores.

Pero no te dás cuenta que decir que un campo númerico es 0 no es
lo mismo que decir que es 'vacío'? O que es null?
Si es 0 tiene un valor y si es null no se conoce el valor.
Puede haber casos en que 1 ó 1000 como default tengan mas sentido
que un 0, dependiendo de la situación que estemos modelando.

Con '' la cosa es mas confusa porque aunque tenemos un valor que
es la 'cadena vacía', pero es una cadena. Eso no es lo mismo que
decir que es null (no tenemos un valor). Y al igual que con
cualquier otro tipo, dependiendo la situacion un default 'A' puede
tener mas sentido que '' como default.

Lo mismo para las fechas. Si proporcionamos una fecha (como default
o como sea) tendrá que ser una fecha. Si desconocemos la fecha
ponemos null.

Entonces, independiente del tipo (numérico, caracter, fecha, etc.)
tu problema es de presentación en la aplicación: no quieres ver
los NULL. Con carácteres lo tienes fácil utilizando '' en vez de null
pero con otros tipos ya no funciona ese truco.

Eso puedes solucionarlo en las aplicaciones. Pero también puedes
conseguir lo que quieres, por ejemplo así:
A la tabla original le damos otro nombre y no será accesible desde
las aplicaciones. En esa tabla si debes permitir nulos para esa
columna. Creamos ahora una vista sobre esa tabla con el nombre
original de la tabla y con las mismas columnas. La consulta en la
vista convierte las fechas a varchar y nulos a ''. Con la vista
irán instead of triggers. Los triggers para insert y update
no aceptarán nulos pero convertirán las cadenas '' a nulos en
esa columna para actualizar los datos en la tabla original.

Después puedes utilizar esa vista de la misma forma que estás
utilizando ahora la tabla y tendrás tus 'en blancos'.
La tabla original desaparece (visto desde las aplicaciones, claro)

Otro asunto aparte de todo esto es que con el ejemplo que has puesto
tu mismo has dicho que para pagos en efectivo no existe fecha de
vencimiento. Eso es otra cosa que decir que la fecha se desconoce y
ya se proporcionará mas tarde. Esa es una buena señal de que tienes
dos tipos de entidades en una misma tabla y eso no es bueno.
Tendrías que reevaluar tu diseño y normalizar. Pero, insisto, esto
es aparte de lo de los nulos y 'en blancos'; y mas importante.

Si no le vés pies ni cabeza a como te he explicado como puedes
montar esa vista, dímelo y te pongo un ejemplo.
Pero ahora me voy a dormir!

Saludos,
Carlos

en mis aplicasiones no tengo ningun problema en controlar los null, me
refiero a la presentacion del sql en sus datos.
a eso me refiero!!!!!!!!!!!!!!!!!!!

Luis


"Carlos M. Calvelo" escribió en el mensaje de
noticias
news:
Hola Luis,

On 20 okt, 22:53, "Luis Mata"
wrote:

Una campo no necesariamente tiene que contener un dato a menos que fue un
indice, a eso me voy cuando uno crea un campo asigna un default o aveces
no,
y ese aveces no se convierte en null, y eso no me agrada mucho desde el
vfp
controlo el null, el usuario no lo llega a ver
pero cuando abro la tabla parece una hoja con borrones, a eso me refiero.
asi como el campo numerico tienen su default 0, o el caracter su defalt es
'', el datemite o es el getdate() o el null
y getdate como default puede provocar confusiones si el dato es obviado (o
se coloca cualquiera para salir de cualquier restriccion) e inserta la
fecha
actual, lo que me obliga a usar un campo adicional para controlar si es o
no
el dato correcto...
y si le dejo null ya lo comente anteriormente asi que preferiria un valor
vacio a culquiera de las 2 anteriores.

Pero no te dás cuenta que decir que un campo númerico es 0 no es
lo mismo que decir que es 'vacío'? O que es null?
Si es 0 tiene un valor y si es null no se conoce el valor.
Puede haber casos en que 1 ó 1000 como default tengan mas sentido
que un 0, dependiendo de la situación que estemos modelando.

Con '' la cosa es mas confusa porque aunque tenemos un valor que
es la 'cadena vacía', pero es una cadena. Eso no es lo mismo que
decir que es null (no tenemos un valor). Y al igual que con
cualquier otro tipo, dependiendo la situacion un default 'A' puede
tener mas sentido que '' como default.

Lo mismo para las fechas. Si proporcionamos una fecha (como default
o como sea) tendrá que ser una fecha. Si desconocemos la fecha
ponemos null.

Entonces, independiente del tipo (numérico, caracter, fecha, etc.)
tu problema es de presentación en la aplicación: no quieres ver
los NULL. Con carácteres lo tienes fácil utilizando '' en vez de null
pero con otros tipos ya no funciona ese truco.

Eso puedes solucionarlo en las aplicaciones. Pero también puedes
conseguir lo que quieres, por ejemplo así:
A la tabla original le damos otro nombre y no será accesible desde
las aplicaciones. En esa tabla si debes permitir nulos para esa
columna. Creamos ahora una vista sobre esa tabla con el nombre
original de la tabla y con las mismas columnas. La consulta en la
vista convierte las fechas a varchar y nulos a ''. Con la vista
irán instead of triggers. Los triggers para insert y update
no aceptarán nulos pero convertirán las cadenas '' a nulos en
esa columna para actualizar los datos en la tabla original.

Después puedes utilizar esa vista de la misma forma que estás
utilizando ahora la tabla y tendrás tus 'en blancos'.
La tabla original desaparece (visto desde las aplicaciones, claro)

Otro asunto aparte de todo esto es que con el ejemplo que has puesto
tu mismo has dicho que para pagos en efectivo no existe fecha de
vencimiento. Eso es otra cosa que decir que la fecha se desconoce y
ya se proporcionará mas tarde. Esa es una buena señal de que tienes
dos tipos de entidades en una misma tabla y eso no es bueno.
Tendrías que reevaluar tu diseño y normalizar. Pero, insisto, esto
es aparte de lo de los nulos y 'en blancos'; y mas importante.

Si no le vés pies ni cabeza a como te he explicado como puedes
montar esa vista, dímelo y te pongo un ejemplo.
Pero ahora me voy a dormir!

Saludos,
Carlos