consulta sobre fecha

Hola Luis,

On 18 okt, 01:38, "Luis Mata"
wrote:

Hno respeto tu opinion, pero mi problema no se radica en el diseño sino en
el diseño si bien FoxPro el fecha vacia lo representa con //, no solo he
tenido problemas en este proceso sino en otros.

El problema no solo es de diseño, sino que también estás encerrado
en el mundillo cultural de Foxpro y tratas de traer un modismo
específico de ese mundo que ha formado tu forma de pensar a
otro mundo donde eso no tiene significado. Eso es normal pero
hay que ser consciente de ello.

Repito que Žla fecha vacíaŽ no existe. Una fecha es una fecha y
tanto // como null no son fechas. De null ya se sabe que no es
una fecha. Si el campo no puede tener null entonces tiene que
tener de por fuerza un valor del tipo de la columna. // no es
de ese tipo.

Sigues repitiendo que la fecha vacía tiene una representación (//)
pero no explicas que es una fecha vacía.

Tu explíca a nivel conceptual
1) el significado de "Tengo una fecha y está vacía".
2) y después la diferencia de eso con "No tengo fecha"

y después ya veremos como representamos eso.

la pregunta en si es: sino quiero colocar una fecha especifica en un campo
sea cual fuera la razon ¿Que es lo que le pongo?

Ya se te han dado las opciones que tienes.

Pero aquí tienes otra:
Si tu entiendes la diferencia entre null y // pero no sabes
explicarlo crea un tipo 'FechaALaFoxproByLuisMata' con el clr.
El conjunto de valores que definen ese tipo es:

TodasLasPosiblesFechas UNION {'//'}

Los operadores que van con ese tipo (day, month, year, dateadd,
datediff, <, =, >, etc) tendrán que tener en cuenta ese valor y
todas las operaciones tendrán hacer algo sensato con él. Si tu
entiendes la diferencia entre los dos conceptos (null y 'fecha
vacía') no creo que tengas problemas.
Si de todo eso sacas algo consistente, compártelo con la comunidad,
porque con los nulos no nos va muy bien y quizás tengamos que
considerar 'el valor vacío'. Te harás famoso si lo consigues.

Saludos,
Carlos

Luis pero puedes usar NULL. En VFP el despliegue de la palabra NULL se
puede configurar a la expresion que quieras.


"Luis Mata" escribió en el mensaje
news:

veras, los usuarios son demasiados exquisitos en ese caso, dice que se
confunden y piensan que es credito, ya te imaginas asi que de preferencia
que quede en blanco, en el Fox lo puedo controlar sin problemas pero en el
sql no.

"Victor Koch" <v i c t o r
(arroba)correo(punto)waldbott(punto)com(punto)ar> escribió en el mensaje
de noticias news:%

Hola,

Y porque no guardas en la FV la fecha de emisión para las facturas en
efectivo.


Un Saludo, Víctor Koch



"Luis Mata" escribió en el mensaje
news:

Asi es trabajo en Fox y no tengo problemas con fechas en vacio asi
deberia de ser no les parece ya que en facturas al credito tienen una
fecha de vencimiento pero las que son en efectivo no tienen FV.

Luis


"Germán Valdez" escribió en el mensaje de
noticias news:%

sql no soporta fechas en blanco como lo hace visual foxpro por ejemplo

en blanco es nulo.



"Luis Mata" escribió en el mensaje
news:%

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


Luis
"Alejandro Mesa" escribió en
el mensaje de noticias
news:

Luis Mata,

Blanco?

Ese valor no esta en el dominio de el tipo datetime. Blanco es
traducido a
19000101.

Ejemplo:

declare @t table (
dt datetime NULL
)

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

select * from @t
GO


AMB


"Luis Mata" wrote:

Hola a Todos

Quiero saber cual es el default del DATETIME

Osea quiero insertar en mi Campo fechas y no fechas, en las fechas
no quiero
que se inserte el valor NULL, quiero que se quede en blanco, como lo
hago

Luis

Luis, como ya te dije no veo el problema de que dejes la fecha de
vencimiento en NULL ya que en VFP puedes ajustar el despliegue, pero la
otra opcion que tienes es repetir la misma fecha del documento alli y ya
sería asunto de despliegue en los reportes de mostrar o no esa fecha segun
la factura sea a credito o al contado (efvo). Pero como te dijeron la fecha
de vencimiento no debe ser el atributo que identifique el tipo de factura.
Debes tener otro campo para eso, como por ej., TipoPago, o algo asi.


"Luis Mata" escribió en el mensaje
news:%

Lo que pasa que hay una tabla de Ventas al credito y contado

- Credito tiene fecha de vencimiento
- Efectivo no tienen fecha de vencimiento

- al credito le pongo la fecha que le corresponde como fecha de
vencimiento
- al efectivo no quiero ponerle ni '' ni NULL ni '1900-01-01'osea dejarlo
en blanco

explico que tambien los que son al credito se van a otra tabla que
controla solo doc al credito ahi no tengo este problema.

Luis

"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

Hola Carlos,

El Sat, 18 Oct 2008 05:05:56 -0700 (PDT), Carlos M. Calvelo escribió:

Los operadores que van con ese tipo (day, month, year, dateadd,
datediff, <, =, >, etc) tendrán que tener en cuenta ese valor y
todas las operaciones tendrán hacer algo sensato con él.

Las operaciones que incluyesen un '//' podrían provocar una excepción.
Excepto los operadores '=' y '<>', que esos si que deberían de funcionar
siempre para que un tipo sea un tipo de verdad.

Hacer un datediff de una fecha con un blanco no es muy diferente a hacer
una división por 0 en medio de una consulta. Sería bastante lógico que la
consulta no devolviese ningún resultado. Otra opción es tener un valor
'Indefinido', pero es bastante más complicado.

Si de todo eso sacas algo consistente, compártelo con la comunidad,
porque con los nulos no nos va muy bien y quizás tengamos que
considerar 'el valor vacío'. Te harás famoso si lo consigues.

Pues tampoco me parece muy difícil, lo malo es que los tipos CLR parecen
bastante incómodos de usar.

Yo estoy pensando seriamente crear un tipo "OptionalDate" para mi "RDBMS
Middleware".


Saludos
Alfredo

Hola Pedro,

El Sat, 18 Oct 2008 09:59:08 -0400, Pedro escribió:

Pero como te dijeron la fecha
de vencimiento no debe ser el atributo que identifique el tipo de factura.
Debes tener otro campo para eso, como por ej., TipoPago, o algo asi.

Pues yo creo que identificar el tipo de factura dependiendo de si la fecha
es nula no es una chapuza peor que cualquier otro uso de los nulos. Añadir
una columna como TipoPago crearía más redundancia, y no le acabo de ver
ninguna ventaja.

Aquí lo lógico sería partir la tabla verticalmente a nivel lógico, aunque
si quieres puedes seguir teniendo solo una a nivel físico.


Saludos
Alfredo