consulta sobre fecha
Luis Mata
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
Alejandro Mesa
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
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" <Alejan...@discussions.microsoft.com> escribió en el
mensaje de noticias
news:27094779-D6BF-40DC...@microsoft.com...
Alejandro Mesa
Vuelvo y repito, el valor "vacio" no es parte de el dominio de valores de el
tipo datetime. Si no acepta NULL, entonces debe tener un valor datetime.
AMB
Germán Valdez
en blanco es nulo.
"Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
news:%23rYaz4H...@TK2MSFTNGP02.phx.gbl...
"Fernando A. Gómez F."
>>
>> "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
>>>
>>>
Pos no se puede todo en esta vida. En particular, tienes ahí un error de
diseño que convendría revisar.
Saludos.
Luis Mata
la B.D. MS a corregir eso.
""Fernando A. Gómez F."" <fernando....@gmail.com> escribió en el
mensaje de noticias news:u6ieQlIM...@TK2MSFTNGP04.phx.gbl...
Luis Mata
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" <gfva...@hotmail.com> escribió en el mensaje de noticias
news:%234TvmjI...@TK2MSFTNGP04.phx.gbl...
Carlos M. Calvelo
On 17 okt, 19:31, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
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
Victor Koch arroba punto punto punto
Y porque no guardas en la FV la fecha de emisión para las facturas en
efectivo.
--
Un Saludo, Víctor Koch
"Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
news:eHfky0IM...@TK2MSFTNGP06.phx.gbl...
Luis Mata
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:%23CBerTJ...@TK2MSFTNGP06.phx.gbl...
Luis Mata
- 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" <c_ja...@hotmail.com> escribió en el mensaje de
noticias
news:d43140be-6094-4fff...@v72g2000hsv.googlegroups.com...
Carlos M. Calvelo
On 17 okt, 22:29, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
wrote:
> Lo que pasa que hay una tabla de Ventas al credito y contado
>
> - Credito tiene fecha de vencimiento
> - Efectivo no tienen fecha de vencimiento
Entonces ventas al credito y ventas en efectivo, por muchos
atributos comunes que tengan, son entidades distintas.
Espero que no sea este campo el que determina si una
venta es al crédito o en efectivo, porque entonces estarías
representando dos atributos en una columna.
>
> - 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
'En banco' no existe, no es una fecha. Ya entiendo que
estás hablando en terminos de lo que estás acostumbrado
desde Foxpro, pero '' (si eso es 'en blanco') no es una fecha.
>
> explico que tambien los que son al credito se van a otra tabla que controla
> solo doc al credito ahi no tengo este problema.
Y porque no está la fecha de vencimiento en esa tabla?
Para pagos en efectivo esa fecha no es aplicable. Cuando
un dato no es aplicable (que no es lo mismo que 'desconocido')
entonces no hace falta esa columna. Como lo estoy entendiendo
yo, tienes un poblema de diseño, no de nulos o 'en blancos'.
Quizás estés confundiendo ventas con pagos.
Saludos,
Carlos
"Fernando A. Gómez F."
> 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
Pues es que si una factura no tiene fecha de vencimiento entonces no
tiene fecha y va nulo.
Carlos te preguntó que qué entendías por campo vacío, ya que ni espacios
en blanco, ni nulo ni '' es espacio vacío. ¿Qué es lo que esperas?
Saludos.
Luis Mata
el diseño si bien FoxPro el fecha vacia lo representa con //, no solo he
tenido problemas en este proceso sino en otros.
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? muy aparte de si esta o no
esta diseñado bien, que no todos tenemos el mismo criterio ni logica lo cual
no significa que este mal.
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje de
noticias
news:d2077cdb-16b9-4911...@u28g2000hsc.googlegroups.com...
Juan Diego Bueno
"Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje de
noticias:esYGGHLM...@TK2MSFTNGP03.phx.gbl...
> 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.
>
Lo de que tu problema no radique en el diseño sino en el diseño, no lo acabo
de pillar
> 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? muy aparte de si esta o
> no esta diseñado bien, que no todos tenemos el mismo criterio ni logica lo
> cual no significa que este mal.
Pues un NULL, que no es lo mismo que una cadena vacía o '' ya que entonces
no sería fecha (lo que te han dicho en anteriores posts). Si cara a la
presentación no te gusta que salga NULL, convierte la fecha a cadena y ponla
como cadena vacía cuando sea nula, y cuando tengas que grabar ese dato,
haces la conversión inversa y vuelves a ponerla como fecha. Sql server creo
que te puede hacer la conversión automática de una cadena a fecha si está en
el formato correcto, pero dudo que convierta '' en NULL así que eso deberías
hacerlo tú.
Un saludo
Carlos M. Calvelo
On 18 okt, 01:38, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
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
Pedro
puede configurar a la expresion que quieras.
"Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
news:uh3ezYJM...@TK2MSFTNGP03.phx.gbl...
Pedro
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" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
news:%236JZPcJ...@TK2MSFTNGP06.phx.gbl...
Alfredo Novoa
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
Alfredo Novoa
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
Pedro
> 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.
>
Cómo sería eso ?
Carlos M. Calvelo
On 18 okt, 17:08, Alfredo Novoa <alfred...@gmail.com> wrote:
> 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.
Cierto. Con esta difinicion:
// = 1-1-2008 False
// <> 1-1-2008 True
// = // True
// <> // False
O sea, sin meterse a la lógica de tres valores como con los nulos.
Pero este ya no es el tipo Date, sino el tipo OptionalDate del que
hablas mas adelante.
>
> 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.
A mi si me parece diferente. En concreto 0 es tan número como otro
cualquiera independientemente de la operanción división. En cambio
fecha_en_blanco no es una fecha.
> 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.
El paralelo que tratas de hacer con 0 y con la división de números
no me parece del todo tan obvio, aunque yo también pensé en eso.
a/0 es indefinido porque no podemos encontrar un b tal que a = 0 x b,
o si a también es 0 cualquier b valdría.
El que es especial aquí no es el 0 sino la operación /.
Ni eso implica que indefinido sea un valor normal, sino una
excepción.
>
> > 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".
Qué sea o no difícil/posible hacer algo no es a lo que me refiero.
Me refiero a si tiene sentido y donde está la diferencia fundamental
entre 'tengo una fecha vacía' y 'no tengo fecha' (null)
Quizás tu middelware no conoze el concepto de null pero para ciertos
tipos necesitas un valor especial, sin tener que introducir ese
concepto para todos los tipos. Entonces tendrás un tipo Date y otro
OptionalDate, pero no solo uno. Quizás podría heredar Date de
OptionalDate. Y eso sería paralelo a tener un tipo Integer y otro
distinto OptionalInteger; este ultimo con un valor especial que no
es 0.
Saludos,
Carlos
Carlos M. Calvelo
Es la tercera opción que le doy yo a Luis en mi primer reacción
implementada de esta manera:
la tabla original no es accesible (nivel físico) y se definen dos
vistas sobre esa tabla que son las que representan la partición
vertical (nivel lógico).
Saludos,
Carlos
Pedro
tercera opcion que dices hablas de normalizar la tabla y pensaba que
implicaba la partición física vertical.
Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
lo contrario.
Pero pregunto, cuando se habla de normalizar para dividir esa tabla en dos,
no estamos hablando, entre otras cosas, de obtener dos tablas (físicas) ?
Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
normalizando realmente ?
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje
news:94f8f5e4-96f0-42ca...@d70g2000hsc.googlegroups.com...
Alfredo Novoa
Hola Carlos,
El Sat, 18 Oct 2008 11:17:30 -0700 (PDT), Carlos M. Calvelo escribió:
>> 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.
>
> A mi si me parece diferente. En concreto 0 es tan número como otro
> cualquiera independientemente de la operanción división. En cambio
> fecha_en_blanco no es una fecha.
Bueno, me refería a una vez incluida la fecha en blanco en un tipo como el
OptionalDate. Un 'blanco' sería tan fecha opcional como cualquier otra :-)
> El paralelo que tratas de hacer con 0 y con la división de números
> no me parece del todo tan obvio, aunque yo también pensé en eso.
> a/0 es indefinido porque no podemos encontrar un b tal que a = 0 x b,
> o si a también es 0 cualquier b valdría.
a/0 es indefinido por que el operador '/' no está definido cuando el
divisor es 0. Tu puedes definir operadores para los valores que te da la
gana.
> El que es especial aquí no es el 0 sino la operación /.
Pues yo no le veo nada especial. Por ejemplo el operador raiz cuadrada que
devuelve números reales no está definido para numeros negativos, y entonces
ya serían infinitos valores 'especiales' :-)
> Qué sea o no difícil/posible hacer algo no es a lo que me refiero.
> Me refiero a si tiene sentido y donde está la diferencia fundamental
> entre 'tengo una fecha vacía' y 'no tengo fecha' (null)
Pues en que con el nulo te sales de la lógica de predicados y con la fecha
vacía no.
> Quizás tu middelware no conoze el concepto de null pero para ciertos
> tipos necesitas un valor especial, sin tener que introducir ese
> concepto para todos los tipos. Entonces tendrás un tipo Date y otro
> OptionalDate, pero no solo uno. Quizás podría heredar Date de
> OptionalDate. Y eso sería paralelo a tener un tipo Integer y otro
> distinto OptionalInteger; este ultimo con un valor especial que no
> es 0.
Pues de eso se trata, lo malo es que esos tipos son casi tan peligrosos
como los nulos, y yo no los usaría más que para la presentación.
Por ejemplo puedes tener tablas separadas como siempre y para presentar en
un grid haces una vista actualizable con un outer join rellenando los
huecos con el valor "en blanco" de ese tipo. Así puedes conseguir que si
intentas introducir una letra en una fecha opcional no te deje.
Así necesitas definir menos operadores y ya no habría excepciones. Por
ejemplo DateDiff, AddDays, Year, etc podrían no existir para las fechas
opcionales.
Tampoco se necesitaría usar herencia por que los tipos se podrían crear
fácilmente por composición.
Saludos
Alfredo
Alfredo Novoa
Creas dos vistas actualizables, una para cada tipo de factura, que tiren de
la misma tabla, y no les das permiso a los usuarios para ver la tabla. Así
los usuarios nunca podrán ver los nulos y no se necesita hacer ningún join.
Saludos
Carlos M. Calvelo
On 18 okt, 21:10, "Pedro" <pedritot...@hotmail.es> wrote:
> Me disculpan la ignorancia en ese tema pero es que no entiendo bien. En la
> tercera opcion que dices hablas de normalizar la tabla y pensaba que
> implicaba la partición física vertical.
Esquema lógico: conjunto de tablas que expone la estructura
de los datos al mundo exterior. Tablas pueden ser tablas base
o vistas (tablas derivadas, virtuales).
Esquema físico: conjunto de 'archivos' en los que se guardan los
datos. Fíjate que digo 'archivos' en vez de tablas aunque puede
haber una correspondencia directa.
Normalizar, que es de lo que hablamos en este caso cuando hablamos
de partición vertical, es un concepto a nivel lógico.
> Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
> lo contrario.
La tabla original antes de la partición vertical es una tabla a
nivel lógico. Si esa tabla base la substituimos por otras dos tablas
base, el mapeo de nivel lógico a físico es de uno a uno.
Esa partición también la podemos hacer con vistas sobre la tabla
original. Entonces las dos tablas a nivel lógico son las vistas
y la tabla original pasa a formar parte del nivel físico. El mapeo
de nivel lógico a nivel físico es de dos a uno. Dos tablas (vistas)
a nivel lógico son representadas a nivel físico en el mismo
'archivo', la tabla base original.
Para los dos casos el esquema a nivel lógico es el mismo, dos tablas.
> Pero pregunto, cuando se habla de normalizar para dividir esa tabla en dos,
> no estamos hablando, entre otras cosas, de obtener dos tablas (físicas) ?
No. A nivel lógico teníamos una tabla y ahora dos.
Eso, independientemente de si tenemos dos tablas base o dos tablas
derivadas (vistas).
Además normalización es un concepto a nivel lógico.
> Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
> normalizando realmente ?
Si. A nivel lógico el resultado es el mismo: dos tablas.
No sé si me he explidado bien. Te aconsejo el libro de
C. Date (An Introduction to Database Systems).
Saludos,
Carlos
Alfredo Novoa
Hola Pedro,
El Sat, 18 Oct 2008 15:10:22 -0400, Pedro escribió:
> Me disculpan la ignorancia en ese tema pero es que no entiendo bien. En la
> tercera opcion que dices hablas de normalizar la tabla y pensaba que
> implicaba la partición física vertical.
La normalización es un concepto lógico y por lo tanto no tendría por que
implicar cambios físicos.
En la práctica muchas veces si los implica por que la tecnología actual no
es como para tirar cohetes. Pero en este caso es bastante fácil evitar la
partición física como te explico en el otro mensaje.
> Ademas me imagino que Luis se referiría a la tabla física, sino habría dicho
> lo contrario.
Más bien habría que suponer lo contrario.
> Si la dejamos igual (una sola física) y hacemos dos vistas, estamos
> normalizando realmente ?
Por supuesto que si, siempre que le ocultemos la tabla a los usuarios.
Saludos
Alfredo
Pedro
>No sé si me he explidado bien.
Mas o menos pero para resumir: en ese caso del que hablamos el campo
FechaVencimiento seguirá de todos modos existiendo en la tabla de la que
habló Luis ? O sea que el "nivel físico" sigue tal cual él lo planteó?
Oye gracias por la explicacion.
Carlos M. Calvelo
On 18 okt, 22:18, Alfredo Novoa <alfred...@gmail.com> wrote:
> Hola Carlos,
>
> El Sat, 18 Oct 2008 11:17:30 -0700 (PDT), Carlos M. Calvelo escribió:
>
> >> 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.
>
> > A mi si me parece diferente. En concreto 0 es tan número como otro
> > cualquiera independientemente de la operanción división. En cambio
> > fecha_en_blanco no es una fecha.
>
> Bueno, me refería a una vez incluida la fecha en blanco en un tipo como el
> OptionalDate. Un 'blanco' sería tan fecha opcional como cualquier otra :-)
>
> > El paralelo que tratas de hacer con 0 y con la división de números
> > no me parece del todo tan obvio, aunque yo también pensé en eso.
> > a/0 es indefinido porque no podemos encontrar un b tal que a = 0 x b,
> > o si a también es 0 cualquier b valdría.
>
> a/0 es indefinido por que el operador '/' no está definido cuando el
> divisor es 0. Tu puedes definir operadores para los valores que te da la
> gana.
Bueno, yo digo por qué no esta definido y tu me dices que no está
definido. :-)
Y claro que puedo definir lo que me dé la gana pero tendrá que
tener algún sentido y seguro que no será sin consecuencias.
>
> > El que es especial aquí no es el 0 sino la operación /.
>
> Pues yo no le veo nada especial. Por ejemplo el operador raiz cuadrada que
> devuelve números reales no está definido para numeros negativos, y entonces
> ya serían infinitos valores 'especiales' :-)
Pero yo decía que 0 no es especial sino la operación /. Pero bueno,
lo dije pensando solo en +,-,x que no tienen ese probema con el 0, ni
con cualquier otro número y claro que se pueden encontrar mas casos
así.
>
> > Qué sea o no difícil/posible hacer algo no es a lo que me refiero.
> > Me refiero a si tiene sentido y donde está la diferencia fundamental
> > entre 'tengo una fecha vacía' y 'no tengo fecha' (null)
>
> Pues en que con el nulo te sales de la lógica de predicados y con la fecha
> vacía no.
No.. ya! Pero eso tiene consecuencias para las operaciones.
Podemos considerar que:
- null=null es True, null<>null es False, otro_valor = null es false,
etc
- y ademas que null es implícitamente un valor para todos los tipos
y ya todos los tipos son opcionales.
No creo que eso vaya a solucionar satisfactoriamente el problema
de la falta de información. Mas bien conduciría a que se normalize
mucho menos que ahora.
Para satisfacer a Luis ese null no será null sino '' o // :-)
>
> > Quizás tu middelware no conoze el concepto de null pero para ciertos
> > tipos necesitas un valor especial, sin tener que introducir ese
> > concepto para todos los tipos. Entonces tendrás un tipo Date y otro
> > OptionalDate, pero no solo uno. Quizás podría heredar Date de
> > OptionalDate. Y eso sería paralelo a tener un tipo Integer y otro
> > distinto OptionalInteger; este ultimo con un valor especial que no
> > es 0.
Me gustaría quedarme con esto que sigue ...
>
> Pues de eso se trata, lo malo es que esos tipos son casi tan peligrosos
> como los nulos, y yo no los usaría más que para la presentación.
>
> Por ejemplo puedes tener tablas separadas como siempre y para presentar en
> un grid haces una vista actualizable con un outer join rellenando los
> huecos con el valor "en blanco" de ese tipo. Así puedes conseguir que si
> intentas introducir una letra en una fecha opcional no te deje.
... porque es donde está explicado de otra forma una de las
soluciones que se le dieron a Luis, pero sin crear nuevos tipos
sino convirtiendo nulos y fechas a varchar en vistas. Evidentemente
esas vistas tienen que ser actualizables para hacer la conversión
inversa.
Saludos,
Carlos
Carlos M. Calvelo
On 18 okt, 23:02, "Pedro" <pedritot...@hotmail.es> wrote:
> >No sé si me he explidado bien.
>
> Mas o menos pero para resumir: en ese caso del que hablamos el campo
> FechaVencimiento seguirá de todos modos existiendo en la tabla de la que
> habló Luis ? O sea que el "nivel físico" sigue tal cual él lo planteó?
>
Si, pero a nivel lógico solo existirá en la tabla (vista)
VENTAS_CREDITO y no en la tabla VENTAS (digamos que así
se llaman las tablas después de la partición)
Pero eso es irrelevante a nivel lógico. Las dos vistas se podrán
convertir en tablas base, la tabla original se borra y las
aplicaciones no se enteran. Ese proceso es reversible: se crean
otra vez las vistas y una tabla a nivel físico y las aplicaciones
seguiran sin enterarse.
Lo más importante es haber diseñado (y normalizado) bien desde el
principio.
Saludos,
Carlos
Pedro
Entendido y gracias de nuevo.
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje
news:673135ef-e126-40da...@h2g2000hsg.googlegroups.com...
"Fernando A. Gómez F."
> Hola Luis,
[SNIP]
> Y porque no está la fecha de vencimiento en esa tabla?
> Para pagos en efectivo esa fecha no es aplicable. Cuando
> un dato no es aplicable (que no es lo mismo que 'desconocido')
> entonces no hace falta esa columna. Como lo estoy entendiendo
> yo, tienes un poblema de diseño, no de nulos o 'en blancos'.
Yo creo eso también. El principal indicador es que el OP quiere meter un
valor en una columna que no admite dicho valor.
> Quizás estés confundiendo ventas con pagos.
>
> Saludos,
> Carlos
Saludos.
"Fernando A. Gómez F."
> Hola Luis:
>
> "Luis Mata" <lm...@hipermercadoceramico.com.pe> escribió en el mensaje
> de noticias:esYGGHLM...@TK2MSFTNGP03.phx.gbl...
>> 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.
>>
>
> Lo de que tu problema no radique en el diseño sino en el diseño, no lo
> acabo de pillar
>
>> 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? muy aparte de
>> si esta o no esta diseñado bien, que no todos tenemos el mismo
>> criterio ni logica lo cual no significa que este mal.
>
> Pues un NULL, que no es lo mismo que una cadena vacía o '' ya que
> entonces no sería fecha (lo que te han dicho en anteriores posts). Si
> cara a la presentación no te gusta que salga NULL, convierte la fecha a
> cadena y ponla como cadena vacía cuando sea nula,
El OP inclusive podría hacer algo como:
select isnull(mi_campo_fecha, ''), ... from ... etc
>y cuando tengas que
> grabar ese dato, haces la conversión inversa y vuelves a ponerla como
> fecha. Sql server creo que te puede hacer la conversión automática de
> una cadena a fecha si está en el formato correcto, pero dudo que
> convierta '' en NULL así que eso deberías hacerlo tú.
>
> Un saludo
>
>
Saludos.
Carlos M. Calvelo
On 19 okt, 18:55, "Fernando A. Gómez F."
<fernando.a.gome...@gmail.com> wrote:
>
> El OP inclusive podría hacer algo como:
>
> select isnull(mi_campo_fecha, ''), ... from ... etc
>
Eso no funcionaría porque siendo la columna del tipo
datetime convertiría automáticamente el '' a la fecha
cero (19000101 00:00:00.000)
Prueba esto:
select
isnull(fecha,'') as fecha
from
( select getdate() as fecha
union
select null
) x
Saludos,
Carlos
Luis Mata
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" <c_ja...@hotmail.com> escribió en el mensaje de
noticias
Pedro
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.
Luis Mata
"Pedro" <pedri...@hotmail.es> escribi� en el mensaje de noticias
news:%23HH1Qmv...@TK2MSFTNGP03.phx.gbl...
>> 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
Carlos M. Calvelo
On 20 okt, 22:53, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
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
Luis Mata
refiero a la presentacion del sql en sus datos.
a eso me refiero!!!!!!!!!!!!!!!!!!!
Luis
"Carlos M. Calvelo" <c_ja...@hotmail.com> escribió en el mensaje de
noticias
news:e0ba17de-668b-4168...@v72g2000hsv.googlegroups.com...
Pedro
> refiero a la presentacion del sql en sus datos.
> a eso me refiero!!!!!!!!!!!!!!!!!!!
>
Si te refieres al SQL Management Studio, ese no es un lugar para los
usuarios de las aplicaciones.
"Fernando A. Gómez F."
> 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
>
*sigh*
:(
"Fernando A. Gómez F."
Oops, cierto. Qué tal:
select (isnull(convert(varchar, campo_fecha), '')) from tabla
;P
Carlos M. Calvelo
wrote:
> 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!!!!!!!!!!!!!!!!!!!
>
:o
Mi perplejidad.. es que no sé...
Me he quedado patitieso. :(
Suerte con los nulos.
"Fernando A. Gómez F."
Servidor con Windows: EUR 1,500
Licencia SQL Server 2005: EUR 700
Querer meter blancos a huevo en un campo de fecha para que se vean
bonitos los datos en la DB: no tiene precio
:D
Leonardo Azpurua
> 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!!!!!!!!!!!!!!!!!!!
¡¡SQL no presenta datos!!
Que confusión espantosa tienes.
SQL le entrega los datos a la aplicación (tu aplicación) y es la aplicación
la responsable de presentarlos.
Una fecha no definida se representa mediante NULL. Y si los datos no se
presentan como tu quieres, es porque tienes problemas con la representación
de NULL como fecha. No se por qué te cuesta tanto entenderlo.
Salud!
Leonardo Azpurua
""Fernando A. Gómez F."" <fernando....@gmail.com> escribió en el
mensaje news:%23jgE0S8...@TK2MSFTNGP05.phx.gbl...
:-)
Cesar Granjeno Chavero
Por tanto, una respuesta concisa y no un debate es requerido en este tipo de situaciones, va mi aporte, con el unico objetivo de proporcionar una ayuda para conseguir ese valioso tiempo.
En una aplicacion requeria que cuando una columna de fecha devuelta por el SP ejecutando en SQL2K5 enviara un datetime con valor 19000101 la aplicacion mostrara cadena vacia.
La empresa requeria por situaciones que no van al caso discutir en el alcance de este for que el SP fuera el que "presentara" los datos, estas son las lineas que funcionaron para mi:
SELECT CASE WHEN CONVERT(VARCHAR, Fecha_Ficticia1, 112) = '19000101' THEN '' ELSE CONVERT(VARCHAR, Fecha_Ficticia1) END,
Dato2,
Dato3
FROM Tabla_Ficticia
> On Friday, October 17, 2008 12:20 PM 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
>> On Friday, October 17, 2008 12:31 PM AlejandroMes wrote:
>> 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:
>>> On Friday, October 17, 2008 1:31 PM 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
>>>
>>>
>>> Luis
>>> "Alejandro Mesa" <Alejan...@discussions.microsoft.com> escribi?? en el
>>> mensaje de noticias
>>> news:27094779-D6BF-40DC...@microsoft.com...
>>>> On Friday, October 17, 2008 2:45 PM AlejandroMes wrote:
>>>> Luis Mata,
>>>>
>>>> Vuelvo y repito, el valor "vacio" no es parte de el dominio de valores de el
>>>> tipo datetime. Si no acepta NULL, entonces debe tener un valor datetime.
>>>>
>>>>
>>>> AMB
>>>>
>>>> "Luis Mata" wrote:
>>>>> On Friday, October 17, 2008 2:48 PM Germ?n Valdez wrote:
>>>>> sql no soporta fechas en blanco como lo hace visual foxpro por ejemplo
>>>>>
>>>>> en blanco es nulo.
>>>>>
>>>>>
>>>>>
>>>>> "Luis Mata" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje
>>>>>> On Friday, October 17, 2008 2:52 PM fernando.a.gomez. wrote:
>>>>>> Luis Mata wrote:
>>>>>>
>>>>>> Pos no se puede todo en esta vida. En particular, tienes ah?? un error de
>>>>>> dise??o que convendr??a revisar.
>>>>>>
>>>>>> Saludos.
>>>>>>> On Friday, October 17, 2008 3:17 PM Luis Mata wrote:
>>>>>>> asi es porque null se puede controlar en base de codigos pero se ve feo en
>>>>>>> la B.D. MS a corregir eso.
>>>>>>>> On Friday, October 17, 2008 3:18 PM Luis Mata wrote:
>>>>>>>> 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" <gfva...@hotmail.com> escribi? en el mensaje de noticias
>>>>>>>> news:%234TvmjI...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>> On Friday, October 17, 2008 4:21 PM Victor Koch wrote:
>>>>>>>>> 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" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje
>>>>>>>>>> On Friday, October 17, 2008 4:23 PM Luis Mata wrote:
>>>>>>>>>> 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:%23CBerTJ...@TK2MSFTNGP06.phx.gbl...
>>>>>>>>>>> On Friday, October 17, 2008 4:58 PM fernando.a.gomez. wrote:
>>>>>>>>>>> Luis Mata wrote:
>>>>>>>>>>>
>>>>>>>>>>> Pues es que si una factura no tiene fecha de vencimiento entonces no
>>>>>>>>>>> tiene fecha y va nulo.
>>>>>>>>>>>
>>>>>>>>>>> Carlos te pregunt? que qu? entend?as por campo vac?o, ya que ni espacios
>>>>>>>>>>> en blanco, ni nulo ni '' es espacio vac?o. ?Qu? es lo que esperas?
>>>>>>>>>>>
>>>>>>>>>>> Saludos.
>>>>>>>>>>>> On Friday, October 17, 2008 7:38 PM 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.
>>>>>>>>>>>>
>>>>>>>>>>>> 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? muy aparte de si esta o no
>>>>>>>>>>>> esta dise?ado bien, que no todos tenemos el mismo criterio ni logica lo cual
>>>>>>>>>>>> no significa que este mal.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> "Carlos M. Calvelo" <c_ja...@hotmail.com> escribi? en el mensaje de
>>>>>>>>>>>> noticias
>>>>>>>>>>>> news:d2077cdb-16b9-4911...@u28g2000hsc.googlegroups.com...
>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>
>>>>>>>>>>>> On 17 okt, 22:29, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Entonces ventas al credito y ventas en efectivo, por muchos
>>>>>>>>>>>> atributos comunes que tengan, son entidades distintas.
>>>>>>>>>>>>
>>>>>>>>>>>> Espero que no sea este campo el que determina si una
>>>>>>>>>>>> venta es al cr?dito o en efectivo, porque entonces estar?as
>>>>>>>>>>>> representando dos atributos en una columna.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> 'En banco' no existe, no es una fecha. Ya entiendo que
>>>>>>>>>>>> est?s hablando en terminos de lo que est?s acostumbrado
>>>>>>>>>>>> desde Foxpro, pero '' (si eso es 'en blanco') no es una fecha.
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Y porque no est? la fecha de vencimiento en esa tabla?
>>>>>>>>>>>> Para pagos en efectivo esa fecha no es aplicable. Cuando
>>>>>>>>>>>> un dato no es aplicable (que no es lo mismo que 'desconocido')
>>>>>>>>>>>> entonces no hace falta esa columna. Como lo estoy entendiendo
>>>>>>>>>>>> yo, tienes un poblema de dise?o, no de nulos o 'en blancos'.
>>>>>>>>>>>> Quiz?s est?s confundiendo ventas con pagos.
>>>>>>>>>>>>
>>>>>>>>>>>> Saludos,
>>>>>>>>>>>> Carlos
>>>>>>>>>>>>> On Friday, October 17, 2008 10:31 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 17 okt, 19:31, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>> sta
>>>>>>>>>>>>> s.
>>>>>>>>>>>>> e
>>>>>>>>>>>>>
>>>>>>>>>>>>> Puedes explicar qu=E9 es lo que entiendes tu por 'campo vac=EDo',
>>>>>>>>>>>>> pero no nulo? Y por qu=E9 no puede ser nulo?
>>>>>>>>>>>>> Puedes tratar de explicar tambi=E9n que regla es la que requiere que
>>>>>>>>>>>>> 'quede vac=EDo'? O sea, qu=E9 significado tiene el 'estar vac=EDo'?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Tienes tres opciones:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 1) permitir que el campo sea nulo en los registros para los que se
>>>>>>>>>>>>> 'requiere' que ese campo quede 'vac=EDo'.
>>>>>>>>>>>>> 2) utilizar un valor especial como 19000101 para se=F1alar 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 =FAltima opci=F3n es interesante en el caso de que se espere que para
>>>>>>>>>>>>> la gran mayor=EDa de los registos la fecha va a quedar vac=EDa.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Para todas las opciones puedes tambi=E9n al hacer una consulta,
>>>>>>>>>>>>> convertir las fechas a tipo char o varchar e interpretar los
>>>>>>>>>>>>> nulos o el valor especial como '' (cadena vac=EDa). 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 =FAltimo 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 =3D '19000101' then ''
>>>>>>>>>>>>> else convert(varchar, dt, 121)
>>>>>>>>>>>>> end as FechaChar
>>>>>>>>>>>>> from @t
>>>>>>>>>>>>> ----
>>>>>>>>>>>>>
>>>>>>>>>>>>> Vistas otras reacciones creo que aqu=ED se est=E1n confundiendo los
>>>>>>>>>>>>> nulos como marca de falta de informaci=F3n con la presentaci=F3n
>>>>>>>>>>>>> de ese hecho a los usuarios en las aplicaciones.
>>>>>>>>>>>>> Este =FAltimo ejemplo deja claro que los nulos no tienen ni por
>>>>>>>>>>>>> que llegar a las aplicaciones (piensa en vistas), para cuanto
>>>>>>>>>>>>> mas a la presentaci=F3n a los usuarios.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>> On Friday, October 17, 2008 10:31 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 17 okt, 22:29, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Entonces ventas al credito y ventas en efectivo, por muchos
>>>>>>>>>>>>>> atributos comunes que tengan, son entidades distintas.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Espero que no sea este campo el que determina si una
>>>>>>>>>>>>>> venta es al cr=E9dito o en efectivo, porque entonces estar=EDas
>>>>>>>>>>>>>> representando dos atributos en una columna.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> 'En banco' no existe, no es una fecha. Ya entiendo que
>>>>>>>>>>>>>> est=E1s hablando en terminos de lo que est=E1s acostumbrado
>>>>>>>>>>>>>> desde Foxpro, pero '' (si eso es 'en blanco') no es una fecha.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Y porque no est=E1 la fecha de vencimiento en esa tabla?
>>>>>>>>>>>>>> Para pagos en efectivo esa fecha no es aplicable. Cuando
>>>>>>>>>>>>>> un dato no es aplicable (que no es lo mismo que 'desconocido')
>>>>>>>>>>>>>> entonces no hace falta esa columna. Como lo estoy entendiendo
>>>>>>>>>>>>>> yo, tienes un poblema de dise=F1o, no de nulos o 'en blancos'.
>>>>>>>>>>>>>> Quiz=E1s est=E9s confundiendo ventas con pagos.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>> On Saturday, October 18, 2008 4:02 AM Juan Diego Bueno wrote:
>>>>>>>>>>>>>>> Hola Luis:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> "Luis Mata" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje de
>>>>>>>>>>>>>>> noticias:esYGGHLM...@TK2MSFTNGP03.phx.gbl...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Lo de que tu problema no radique en el dise?o sino en el dise?o, no lo acabo
>>>>>>>>>>>>>>> de pillar
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Pues un NULL, que no es lo mismo que una cadena vac?a o '' ya que entonces
>>>>>>>>>>>>>>> no ser?a fecha (lo que te han dicho en anteriores posts). Si cara a la
>>>>>>>>>>>>>>> presentaci?n no te gusta que salga NULL, convierte la fecha a cadena y ponla
>>>>>>>>>>>>>>> como cadena vac?a cuando sea nula, y cuando tengas que grabar ese dato,
>>>>>>>>>>>>>>> haces la conversi?n inversa y vuelves a ponerla como fecha. Sql server creo
>>>>>>>>>>>>>>> que te puede hacer la conversi?n autom?tica de una cadena a fecha si est? en
>>>>>>>>>>>>>>> el formato correcto, pero dudo que convierta '' en NULL as? que eso deber?as
>>>>>>>>>>>>>>> hacerlo t?.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Un saludo
>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 9:48 AM Pedro wrote:
>>>>>>>>>>>>>>>> Luis pero puedes usar NULL. En VFP el despliegue de la palabra NULL se
>>>>>>>>>>>>>>>> puede configurar a la expresion que quieras.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> "Luis Mata" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje
>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 9:59 AM Pedro wrote:
>>>>>>>>>>>>>>>>> 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" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje
>>>>>>>>>>>>>>>>> news:%236JZPcJ...@TK2MSFTNGP06.phx.gbl...
>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 11:08 AM Alfredo Novoa wrote:
>>>>>>>>>>>>>>>>>> Hola Carlos,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> El Sat, 18 Oct 2008 05:05:56 -0700 (PDT), Carlos M. Calvelo escribi?:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 11:14 AM Alfredo Novoa wrote:
>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> El Sat, 18 Oct 2008 09:59:08 -0400, Pedro escribi?:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 12:51 PM Pedro wrote:
>>>>>>>>>>>>>>>>>>>> C?mo ser?a eso ?
>>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 3:10 PM Pedro wrote:
>>>>>>>>>>>>>>>>>>>>> Me disculpan la ignorancia en ese tema pero es que no entiendo bien. En la
>>>>>>>>>>>>>>>>>>>>> tercera opcion que dices hablas de normalizar la tabla y pensaba que
>>>>>>>>>>>>>>>>>>>>> implicaba la partici?n f?sica vertical.
>>>>>>>>>>>>>>>>>>>>> Ademas me imagino que Luis se referir?a a la tabla f?sica, sino habr?a dicho
>>>>>>>>>>>>>>>>>>>>> lo contrario.
>>>>>>>>>>>>>>>>>>>>> Pero pregunto, cuando se habla de normalizar para dividir esa tabla en dos,
>>>>>>>>>>>>>>>>>>>>> no estamos hablando, entre otras cosas, de obtener dos tablas (f?sicas) ?
>>>>>>>>>>>>>>>>>>>>> Si la dejamos igual (una sola f?sica) y hacemos dos vistas, estamos
>>>>>>>>>>>>>>>>>>>>> normalizando realmente ?
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> "Carlos M. Calvelo" <c_ja...@hotmail.com> escribi? en el mensaje
>>>>>>>>>>>>>>>>>>>>> news:94f8f5e4-96f0-42ca...@d70g2000hsc.googlegroups.com...
>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> On 18 okt, 18:51, "Pedro" <pedritot...@hotmail.es> wrote:
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Es la tercera opci?n que le doy yo a Luis en mi primer reacci?n
>>>>>>>>>>>>>>>>>>>>> implementada de esta manera:
>>>>>>>>>>>>>>>>>>>>> la tabla original no es accesible (nivel f?sico) y se definen dos
>>>>>>>>>>>>>>>>>>>>> vistas sobre esa tabla que son las que representan la partici?n
>>>>>>>>>>>>>>>>>>>>> vertical (nivel l?gico).
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 4:18 PM Alfredo Novoa wrote:
>>>>>>>>>>>>>>>>>>>>>> Hola Carlos,
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> El Sat, 18 Oct 2008 11:17:30 -0700 (PDT), Carlos M. Calvelo escribi?:
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Bueno, me refer?a a una vez incluida la fecha en blanco en un tipo como el
>>>>>>>>>>>>>>>>>>>>>> OptionalDate. Un 'blanco' ser?a tan fecha opcional como cualquier otra :-)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> a/0 es indefinido por que el operador '/' no est? definido cuando el
>>>>>>>>>>>>>>>>>>>>>> divisor es 0. Tu puedes definir operadores para los valores que te da la
>>>>>>>>>>>>>>>>>>>>>> gana.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Pues yo no le veo nada especial. Por ejemplo el operador raiz cuadrada que
>>>>>>>>>>>>>>>>>>>>>> devuelve n?meros reales no est? definido para numeros negativos, y entonces
>>>>>>>>>>>>>>>>>>>>>> ya ser?an infinitos valores 'especiales' :-)
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Pues en que con el nulo te sales de la l?gica de predicados y con la fecha
>>>>>>>>>>>>>>>>>>>>>> vac?a no.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Pues de eso se trata, lo malo es que esos tipos son casi tan peligrosos
>>>>>>>>>>>>>>>>>>>>>> como los nulos, y yo no los usar?a m?s que para la presentaci?n.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Por ejemplo puedes tener tablas separadas como siempre y para presentar en
>>>>>>>>>>>>>>>>>>>>>> un grid haces una vista actualizable con un outer join rellenando los
>>>>>>>>>>>>>>>>>>>>>> huecos con el valor "en blanco" de ese tipo. As? puedes conseguir que si
>>>>>>>>>>>>>>>>>>>>>> intentas introducir una letra en una fecha opcional no te deje.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> As? necesitas definir menos operadores y ya no habr?a excepciones. Por
>>>>>>>>>>>>>>>>>>>>>> ejemplo DateDiff, AddDays, Year, etc podr?an no existir para las fechas
>>>>>>>>>>>>>>>>>>>>>> opcionales.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Tampoco se necesitar?a usar herencia por que los tipos se podr?an crear
>>>>>>>>>>>>>>>>>>>>>> f?cilmente por composici?n.
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>> Saludos
>>>>>>>>>>>>>>>>>>>>>> Alfredo
>>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 4:24 PM Alfredo Novoa wrote:
>>>>>>>>>>>>>>>>>>>>>>> El Sat, 18 Oct 2008 12:51:16 -0400, Pedro escribi?:
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Creas dos vistas actualizables, una para cada tipo de factura, que tiren de
>>>>>>>>>>>>>>>>>>>>>>> la misma tabla, y no les das permiso a los usuarios para ver la tabla. As?
>>>>>>>>>>>>>>>>>>>>>>> los usuarios nunca podr?n ver los nulos y no se necesita hacer ning?n join.
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>> Saludos
>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 4:31 PM Alfredo Novoa wrote:
>>>>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> El Sat, 18 Oct 2008 15:10:22 -0400, Pedro escribi?:
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> La normalizaci?n es un concepto l?gico y por lo tanto no tendr?a por que
>>>>>>>>>>>>>>>>>>>>>>>> implicar cambios f?sicos.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> En la pr?ctica muchas veces si los implica por que la tecnolog?a actual no
>>>>>>>>>>>>>>>>>>>>>>>> es como para tirar cohetes. Pero en este caso es bastante f?cil evitar la
>>>>>>>>>>>>>>>>>>>>>>>> partici?n f?sica como te explico en el otro mensaje.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> M?s bien habr?a que suponer lo contrario.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Por supuesto que si, siempre que le ocultemos la tabla a los usuarios.
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>> Saludos
>>>>>>>>>>>>>>>>>>>>>>>> Alfredo
>>>>>>>>>>>>>>>>>>>>>>>>> On Saturday, October 18, 2008 5:02 PM Pedro wrote:
>>>>>>>>>>>>>>>>>>>>>>>>> Mas o menos pero para resumir: en ese caso del que hablamos el campo
>>>>>>>>>>>>>>>>>>>>>>>>> FechaVencimiento seguir? de todos modos existiendo en la tabla de la que
>>>>>>>>>>>>>>>>>>>>>>>>> habl? Luis ? O sea que el "nivel f?sico" sigue tal cual ?l lo plante??
>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>> Oye gracias por la explicacion.
>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 9:14 AM Pedro wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>> Ok.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Entendido y gracias de nuevo.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> "Carlos M. Calvelo" <c_ja...@hotmail.com> escribi? en el mensaje
>>>>>>>>>>>>>>>>>>>>>>>>>> news:673135ef-e126-40da...@h2g2000hsg.googlegroups.com...
>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 23:02, "Pedro" <pedritot...@hotmail.es> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Si, pero a nivel l?gico solo existir? en la tabla (vista)
>>>>>>>>>>>>>>>>>>>>>>>>>> VENTAS_CREDITO y no en la tabla VENTAS (digamos que as?
>>>>>>>>>>>>>>>>>>>>>>>>>> se llaman las tablas despu?s de la partici?n)
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Pero eso es irrelevante a nivel l?gico. Las dos vistas se podr?n
>>>>>>>>>>>>>>>>>>>>>>>>>> convertir en tablas base, la tabla original se borra y las
>>>>>>>>>>>>>>>>>>>>>>>>>> aplicaciones no se enteran. Ese proceso es reversible: se crean
>>>>>>>>>>>>>>>>>>>>>>>>>> otra vez las vistas y una tabla a nivel f?sico y las aplicaciones
>>>>>>>>>>>>>>>>>>>>>>>>>> seguiran sin enterarse.
>>>>>>>>>>>>>>>>>>>>>>>>>> Lo m?s importante es haber dise?ado (y normalizado) bien desde el
>>>>>>>>>>>>>>>>>>>>>>>>>> principio.
>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 12:53 PM fernando.a.gomez. wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>> [SNIP]
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Yo creo eso tambi?n. El principal indicador es que el OP quiere meter un
>>>>>>>>>>>>>>>>>>>>>>>>>>> valor en una columna que no admite dicho valor.
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 12:55 PM fernando.a.gomez. wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Juan Diego Bueno wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> El OP inclusive podr?a hacer algo como:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> select isnull(mi_campo_fecha, ''), ... from ... etc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:03 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 01:38, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> en
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> El problema no solo es de dise=F1o, sino que tambi=E9n est=E1s encerrado
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> en el mundillo cultural de Foxpro y tratas de traer un modismo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> espec=EDfico 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 =B4la fecha vac=EDa=B4 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=EDa tiene una representaci=F3n (//)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pero no explicas que es una fecha vac=EDa.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tu expl=EDca a nivel conceptual
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 1) el significado de "Tengo una fecha y est=E1 vac=EDa".
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 2) y despu=E9s la diferencia de eso con "No tengo fecha"
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> y despu=E9s ya veremos como representamos eso.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> o
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ya se te han dado las opciones que tienes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero aqu=ED 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, <, =3D, >, etc) tendr=E1n que tener en cuenta ese valor y
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> todas las operaciones tendr=E1n hacer algo sensato con =E9l. Si tu
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entiendes la diferencia entre los dos conceptos (null y 'fecha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vac=EDa') no creo que tengas problemas.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Si de todo eso sacas algo consistente, comp=E1rtelo con la comunidad,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> porque con los nulos no nos va muy bien y quiz=E1s tengamos que
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> considerar 'el valor vac=EDo'. Te har=E1s famoso si lo consigues.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:03 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Alfredo,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 17:08, Alfredo Novoa <alfred...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> .
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nar
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Cierto. Con esta difinicion:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // =3D 1-1-2008 False
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // <> 1-1-2008 True
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // =3D // True
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> // <> // False
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> O sea, sin meterse a la l=F3gica de tres valores como con los nulos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero este ya no es el tipo Date, sino el tipo OptionalDate del que
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> hablas mas adelante.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A mi si me parece diferente. En concreto 0 es tan n=FAmero como otro
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cualquiera independientemente de la operanci=F3n divisi=F3n. En cambio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fecha_en_blanco no es una fecha.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> r
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> El paralelo que tratas de hacer con 0 y con la divisi=F3n de n=FAmeros
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no me parece del todo tan obvio, aunque yo tambi=E9n pens=E9 en eso.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a/0 es indefinido porque no podemos encontrar un b tal que a =3D 0 x b,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> o si a tambi=E9n es 0 cualquier b valdr=EDa.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> El que es especial aqu=ED no es el 0 sino la operaci=F3n /.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Ni eso implica que indefinido sea un valor normal, sino una
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> excepci=F3n.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Qu=E9 sea o no dif=EDcil/posible hacer algo no es a lo que me refiero.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Me refiero a si tiene sentido y donde est=E1 la diferencia fundamental
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> entre 'tengo una fecha vac=EDa' y 'no tengo fecha' (null)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Quiz=E1s tu middelware no conoze el concepto de null pero para ciertos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tipos necesitas un valor especial, sin tener que introducir ese
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> concepto para todos los tipos. Entonces tendr=E1s un tipo Date y otro
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OptionalDate, pero no solo uno. Quiz=E1s podr=EDa heredar Date de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> OptionalDate. Y eso ser=EDa paralelo a tener un tipo Integer y otro
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> distinto OptionalInteger; este ultimo con un valor especial que no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> es 0.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:03 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 18:51, "Pedro" <pedritot...@hotmail.es> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> co, aunque
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Es la tercera opci=F3n que le doy yo a Luis en mi primer reacci=F3n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> implementada de esta manera:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> la tabla original no es accesible (nivel f=EDsico) y se definen dos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vistas sobre esa tabla que son las que representan la partici=F3n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> vertical (nivel l=F3gico).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:04 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 21:10, "Pedro" <pedritot...@hotmail.es> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> la
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Esquema l=F3gico: conjunto de tablas que expone la estructura
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> de los datos al mundo exterior. Tablas pueden ser tablas base
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> o vistas (tablas derivadas, virtuales).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Esquema f=EDsico: conjunto de 'archivos' en los que se guardan los
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> datos. F=EDjate que digo 'archivos' en vez de tablas aunque puede
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> haber una correspondencia directa.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Normalizar, que es de lo que hablamos en este caso cuando hablamos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> de partici=F3n vertical, es un concepto a nivel l=F3gico.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> =EDa dicho
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> La tabla original antes de la partici=F3n vertical es una tabla a
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> nivel l=F3gico. Si esa tabla base la substituimos por otras dos tablas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> base, el mapeo de nivel l=F3gico a f=EDsico es de uno a uno.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Esa partici=F3n tambi=E9n la podemos hacer con vistas sobre la tabla
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> original. Entonces las dos tablas a nivel l=F3gico son las vistas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> y la tabla original pasa a formar parte del nivel f=EDsico. El mapeo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> de nivel l=F3gico a nivel f=EDsico es de dos a uno. Dos tablas (vistas)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> a nivel l=F3gico son representadas a nivel f=EDsico en el mismo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 'archivo', la tabla base original.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Para los dos casos el esquema a nivel l=F3gico es el mismo, dos tablas.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> s,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No. A nivel l=F3gico ten=EDamos una tabla y ahora dos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eso, independientemente de si tenemos dos tablas base o dos tablas
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> derivadas (vistas).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Adem=E1s normalizaci=F3n es un concepto a nivel l=F3gico.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Si. A nivel l=F3gico el resultado es el mismo: dos tablas.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No s=E9 si me he explidado bien. Te aconsejo el libro de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> C. Date (An Introduction to Database Systems).
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:04 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Alfredo,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 22:18, Alfredo Novoa <alfred...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> er
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> el
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Bueno, yo digo por qu=E9 no esta definido y tu me dices que no est=E1
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> definido. :-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Y claro que puedo definir lo que me d=E9 la gana pero tendr=E1 que
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tener alg=FAn sentido y seguro que no ser=E1 sin consecuencias.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tonces
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero yo dec=EDa que 0 no es especial sino la operaci=F3n /. Pero bueno,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lo dije pensando solo en +,-,x que no tienen ese probema con el 0, ni
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> con cualquier otro n=FAmero y claro que se pueden encontrar mas casos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> as=ED.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No.. ya! Pero eso tiene consecuencias para las operaciones.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Podemos considerar que:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - null=3Dnull es True, null<>null es False, otro_valor =3D null es false,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> etc
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> - y ademas que null es impl=EDcitamente un valor para todos los tipos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> y ya todos los tipos son opcionales.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> No creo que eso vaya a solucionar satisfactoriamente el problema
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> de la falta de informaci=F3n. Mas bien conducir=EDa a que se normalize
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> mucho menos que ahora.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Para satisfacer a Luis ese null no ser=E1 null sino '' o // :-)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Me gustar=EDa quedarme con esto que sigue ...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> i
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ... porque es donde est=E1 explicado de otra forma una de las
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> soluciones que se le dieron a Luis, pero sin crear nuevos tipos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> sino convirtiendo nulos y fechas a varchar en vistas. Evidentemente
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> esas vistas tienen que ser actualizables para hacer la conversi=F3n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> inversa.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Sunday, October 19, 2008 2:04 PM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Pedro,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 18 okt, 23:02, "Pedro" <pedritot...@hotmail.es> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ue
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> e=F3?
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Si, pero a nivel l=F3gico solo existir=E1 en la tabla (vista)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> VENTAS_CREDITO y no en la tabla VENTAS (digamos que as=ED
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> se llaman las tablas despu=E9s de la partici=F3n)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero eso es irrelevante a nivel l=F3gico. Las dos vistas se podr=E1n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> convertir en tablas base, la tabla original se borra y las
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> aplicaciones no se enteran. Ese proceso es reversible: se crean
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> otra vez las vistas y una tabla a nivel f=EDsico y las aplicaciones
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> seguiran sin enterarse.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Lo m=E1s importante es haber dise=F1ado (y normalizado) bien desde el
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> principio.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, October 20, 2008 4:53 PM 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Carlos M. Calvelo" <c_ja...@hotmail.com> escribi? en el mensaje de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> noticias
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> news:d43140be-6094-4fff...@v72g2000hsv.googlegroups.com...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 17 okt, 19:31, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, October 20, 2008 5:19 PM Pedro wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Monday, October 20, 2008 7:09 PM Luis Mata wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> prefiria en blanco
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Pedro" <pedri...@hotmail.es> escribi? en el mensaje de noticias
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 10:25 AM Luis Mata wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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" <c_ja...@hotmail.com> escribi? en el mensaje de
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> noticias
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> news:e0ba17de-668b-4168...@v72g2000hsv.googlegroups.com...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 20 okt, 22:53, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> 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
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 10:51 AM Pedro wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Si te refieres al SQL Management Studio, ese no es un lugar para los
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> usuarios de las aplicaciones.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 11:42 AM fernando.a.gomez. wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Luis Mata wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> *sigh*
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 12:07 PM fernando.a.gomez. wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Oops, cierto. Qu? tal:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> select (isnull(convert(varchar, campo_fecha), '')) from tabla
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ;P
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 5:35 PM fernando.a.gomez. wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Servidor con Windows: EUR 1,500
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Licencia SQL Server 2005: EUR 700
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Querer meter blancos a huevo en un campo de fecha para que se vean
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> bonitos los datos en la DB: no tiene precio
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 9:21 PM Leonardo Azpurua wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> "Luis Mata" <lm...@hipermercadoceramico.com.pe> escribi? en el mensaje
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> news:uPPucj4...@TK2MSFTNGP04.phx.gbl...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ??SQL no presenta datos!!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Que confusi?n espantosa tienes.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> SQL le entrega los datos a la aplicaci?n (tu aplicaci?n) y es la aplicaci?n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> la responsable de presentarlos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Una fecha no definida se representa mediante NULL. Y si los datos no se
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> presentan como tu quieres, es porque tienes problemas con la representaci?n
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> de NULL como fecha. No se por qu? te cuesta tanto entenderlo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Salud!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Tuesday, October 21, 2008 9:23 PM Leonardo Azpurua wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, October 22, 2008 5:35 AM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Fernando,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 19 okt, 18:55, "Fernando A. G=F3mez F."
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> <fernando.a.gome...@gmail.com> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eso no funcionar=EDa porque siendo la columna del tipo
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> datetime convertir=EDa autom=E1ticamente el '' a la fecha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cero (19000101 00:00:00.000)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Prueba esto:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> select
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> isnull(fecha,'') as fecha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> from
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ( select getdate() as fecha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> union
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> select null
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ) x
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, October 22, 2008 5:35 AM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Hola Luis,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 20 okt, 22:53, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> fp
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> s
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> o
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> cha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero no te d=E1s cuenta que decir que un campo n=FAmerico es 0 no es
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> lo mismo que decir que es 'vac=EDo'? 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 =F3 1000 como default tengan mas sentido
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> que un 0, dependiendo de la situaci=F3n que estemos modelando.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Con '' la cosa es mas confusa porque aunque tenemos un valor que
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> es la 'cadena vac=EDa', 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=E1 que ser una fecha. Si desconocemos la fecha
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ponemos null.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Entonces, independiente del tipo (num=E9rico, caracter, fecha, etc.)
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> tu problema es de presentaci=F3n en la aplicaci=F3n: no quieres ver
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> los NULL. Con car=E1cteres lo tienes f=E1cil utilizando '' en vez de null
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> pero con otros tipos ya no funciona ese truco.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Eso puedes solucionarlo en las aplicaciones. Pero tambi=E9n puedes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> conseguir lo que quieres, por ejemplo as=ED:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> A la tabla original le damos otro nombre y no ser=E1 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=E1n instead of triggers. Los triggers para insert y update
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> no aceptar=E1n nulos pero convertir=E1n las cadenas '' a nulos en
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> esa columna para actualizar los datos en la tabla original.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Despu=E9s puedes utilizar esa vista de la misma forma que est=E1s
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> utilizando ahora la tabla y tendr=E1s 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=E1 mas tarde. Esa es una buena se=F1al de que tienes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> dos tipos de entidades en una misma tabla y eso no es bueno.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Tendr=EDas que reevaluar tu dise=F1o y normalizar. Pero, insisto, esto
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> es aparte de lo de los nulos y 'en blancos'; y mas importante.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Si no le v=E9s pies ni cabeza a como te he explicado como puedes
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> montar esa vista, d=EDmelo y te pongo un ejemplo.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Pero ahora me voy a dormir!
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Saludos,
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Carlos
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On Wednesday, October 22, 2008 5:35 AM Carlos M. Calvelo wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> On 21 okt, 16:25, "Luis Mata" <lm...@hipermercadoceramico.com.pe>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Mi perplejidad.. es que no s=E9...
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Me he quedado patitieso. :(
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Suerte con los nulos.
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> Submitted via EggHeadCafe - Software Developer Portal of Choice
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> ASP.NET Caching Concepts
>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>> http://www.eggheadcafe.com/tutorials/aspnet/78de4d09-b013-48c0-8d4a-bedd68f675f5/aspnet-caching-concepts.aspx