35 respuestas en este tema

[luk2009]

Hay muchas opciones para hacer lo que quieres, tenia ese problema una vez con esa base de datos, pero no lo recuerdo bien, prometo buscar como lo arregle y te paso la idea.
En este link  Delphi Al limite  tienes una serie de funciones que te pueden ayudar a separar la fecha de la hora y guardalas en los campos que quieras o en su defecto si lo guardas en un solo campo, solo tienes que utilizar estas funciones, cuando quieras hacer una consulta utilizando alguna parte de la informacion del campo datetime.
Prometo buscar como lo hice y pasarte la informacion.

[lsedr]

Bueno, no se si esta forma me de algun problema, pero probe esta y me funciona.
Solo que declare nChar a los campos Hora y Fecha.  En que afectaria este cambio ???

delphi

Datamodule3.ADOTable1.fieldByname('Hora').Asstring:=timetostr(time);
Datamodule3.ADOTable1.fieldByname('Fecha').Asstring:=datetostr(date);

[luk2009]

Observa esta pagina para ver si encuentras lo que buscas DELPHI AL LIMITE
alli tienes muchas funciones que te ayudaran a trabajar mejor con fechas y horas. 

[eduarcol]

Como te decia anteriormente

El campo datetime es un campo numerico, donde la parte entera almacena la Fecha y la parte decimal la Hora, si solo le pasas la hora la parte entera quedara en cero, mostrando asi la fecha que estas viendo, para guardar el valor completo podrias hacer esto:

delphi

ADOTable1.FieldByName('Hora').AsDateTime:= Now;

Para ahorrarte problemas, crea un solo campo que guarde la fecha y hora y al recuperarlo por separado lo haces asi:

En firebird seria con un cast

sql

SELECT CAST(mifechahora AS TIME) FROM prueba

Lo que no se es si tu manejador lo soporte, pruebalo y nos comentas

[lsedr]

es que uso SQL  server 2005 express

[eduarcol]

es que uso SQL  server 2005 express

Intentalo, creo que si deberia funcionar

[lsedr]

Declarando el tipo de dato como String me funciona bien, por lo menos me da el resultado que quiero

O exista alguna Funcion SQL server 2005 para manejar los datos por separado ??

[Delphius]

Hola,

El problema aquí es que se trata de varias cosas relacionadas.

En primer lugar se está pasando al campo un dato de tipo TDateTime. Como podemos apreciar, por su nombre tan bien descriptivo, que se trata de un tipo de dato que almacena fecha y hora.

Cuando hacemos algo como:

delphi

DataSet.FieldByName('NombreCampo').AsDateTime := Now;

Estamos diciendo que en el campo se almacene la fecha y hora de ahora.
Lamentablemente ADO no cuenta con la propiedad AsTime y AsDate como para "forzar" que tome la fecha y/o la hora. Y aún, si los tuviera, no resolvería el problema. ya que internamente tanto AsTime como AsDate no son más que un "alias" del uso de TDateTime como lo son el caso de los Fields-no-ADO.

El AsTime y AsDate lo que generan no es más que un TDateTime que contiene una fecha "vacia" y un tiempo "vacío" respectivamente. Pero claro, no existe fecha y tiempo "vacío" entonces con algo ha de llenarse esta parte. Justamente aquí entra los valores mínimo que puede soportar el motor para los tipos Fecha y Hora.
Eso explica el porqué aparece esa fecha... es el valor mínimo. Cuando se trata de un campo TIME en la parte Date del TDateTime se tendrá ese 1/1/1899, mientras que para un campo DATE en la parte Time del DateTime tendremos 00:00.
Internamente el TDateTime se "rellena" con ese dato "vacio" para la parte en cuestión. Luego, cuando trabajamos con el campo debemos obviar este "relleno".

El fallo aquí es que no se está OBVIANDO el relleno.

En segundo lugar, tiene que ver en como está declarado el campo físicamente en la tabla. Hace tiempo que no uso MS SQL Server pero creo que este tiene el tipo de dato DATE, TIME, DATETIME y TIMESTAMP (debería respetar el estándar y tener soporte para estos 4).
Internamente el dato que almacene cuando se pasen los datos estará correcto. El asunto es cuando se recupere...

Volviendo a lo anterior, para que quede claro: Si el campo está definido por ejemplo TIME. Luego si hago:

delphi

DataSet.FieldByName('NombreCampo').AsDateTime := Now;

A lo que hace a los componentes, en Delphi, el TDateTime generado tendrá en la parte Date la fecha de Now, y en Time la hora de Now. Cuando se vuelcan los datos físicamente a la tabla el motor ignorará la parte Date... y registará la hora correctamente.
Lo análogo con un campo DATE también vale: físicamente se ignora la parte Time.

Todo pasa al leer estos datos: Delphi espera TDateTime. Trabaja con ellos por tanto "rellena".

Ahora bien, si en realidad el campo físicamente es de tipo DATETIME es de esperar que esté almacenando tanto la parte Date como Time. Lo que hay que hacer al leer los datos es que se ignore lo que corresponda: se descompone el TDateTime y nos quedamos con lo que nos interese según sea el caso.

Se puede hacer uso de Encode/DecodeDateTime. 

Lo de pretender declarar a los campos como STRING no soluciona las cosas, más bien lo entorpece porque se van a tener que implementar conversiones intermedias e innecesarias.

Otra posibilidad que queda es la no almacenar los datos como de tipo DATE  y TIME sino de forma numérica. Requerirá obviamente de ciertos artilugios, y nos podemos evitar estar luchando con los campos vacios. Básicamente la idea es esta:

1023 = 10:23

1122010 = 01/12/2010

Se almacena números que luego se decodifican y se genera una cadena de texto que será mostrada. Para almacenar se genera el número adecuado y se guarda.

Espero que se entienda la idea.

Saludos,

[Delphius]

Sigo explicando,

Lo que comenta Eduardo es justamente lo que el rollo de mis palabras están diciendo:

Si el tipo de dato del campo es Fecha/Hora se estará guardando ambas partes. Si lo que se busca es que luego se trabaje con las partes de forma individual ha de extraerse dicha parte.

Si se lee el campo directamente con algo como:

delphi

mi_hora := DataSet.FieldByName('MiCampo').AsDateTime;

Luego en mi_hora tendremos el "relleno" en la parte Date, al mostrar este dato deberemos ignorarlo. Por ejemplo:

delphi

ShowMessage(FormatTime('hh:mm',mi_hora));

De forma similar, si leemos el dato de la Fecha ignoramos la hora:

delphi

ShowMessage(FormatDateTime('dd-mm-yyyy',mi_fecha));

O si se desea, decirle al motor, como propone Eduarcol, que el se encargue de devolvernos la parte que nos interesa. MS SQL Server debe respetar el estándar SQL... CAST() es parte del estándar.

La idea es lanzar la consulta y hacer el casting al tipo adecuado.

CAST(Campo AS DATE) para tener la parte Date, y CAST(Campo AS TIME) para tener la parte Time.

Saludos,

[lsedr]

entendi un poco...
pero lo que quiero es tener dos campos diferentes (Fecha) y (Hora), en los cuales pueda almacenar la Fecha y La hora en campos diferentes, cuando un cliente se registre.


Seria necesario utilizar una funcion para esto ??
Donde la colocaria en el Delphi 7 ?

[egostar]

Deberias de mostrarnos una imagen de como está el campo en tu base de datos y que código estás usando para entender bien el asunto, personalmente no le veo el problema, pero no tengo toda la información para aclarar el punto.

Esperamos más información amigo lsedr

Salud OS

[Delphius]

Hola lsedr, en cierto modo es lo mismo que tuvieras un único campo de tipo Fecha/Hora que tener campos específicos para Fecha y Hora.

Te explico: Para los componentes ADO, cuando se lee un campo de tipo DATETIME, TIME o DATE de SQL Server, en Delphi equivalen al tipo TDateTime.

Si es un campo DATE, en Delphi se obtiene un TDateTime con la parte Time "vacío". Si se lee un campo TIME en delphi se obtiene un TDateTime con la parte Date "vacía".

De modo que cuando haces algo como:

delphi

var
mifecha: TDateTime;
 
...
mifecha := ADOQuery1.FieldByNam('MiCampoFecha').AsDateTime;

en mifecha tienes tanto la parte Date como Time. En Time estará vacio. Y como para ti solo te interesa la fecha a mostrar el dato debes ignorar la parte Time. Un ejemplo:

delphi

ShowMessage(FormatDateTime('dd-mm-yyyy',mifecha));

De forma similar, cuando se desea operar con la hora:

delphi

var
 mihora: TDateTime;
 
 ...
 mihora := ADOQuery1.FieldByNam('MiCampoHora').AsDateTime;

Y para mostrar le damos el formato a la horas e ignoramos lo que venga en la parte Date:

delphi

ShowMessage(FormatDateTime('hh:mm',mifecha));

Por ello es que no interesa, en lo que hace a Delphi con ADO, si el campo en la base de datos es TIME, DATE o DATETIME. En ADO todos equivalen al tipo de dato TDateTime.

ADO no tiene soporte al tipo TTime y TDate (como lo tienen el resto de las suites de accedo a base de datos). Y aunque el resto tiene soporte a TTime y TDate, y es posible hacer cosas como:

delphi

var
mifecha: TDate;
 
...
mifecha := DataSet.FieldByName('MiCampoFecha').AsDate;

No solucionamos nada... volvemos a lo mismo. Tanto TDate como TTime son "alias" del tipo TDateTime, la diferencia del TDateTime es que el tipo está diseñado para poner vacio automáticamente la otra parte.

La ventaja de tener dos campos separados, una para la Fecha y otro la Hora es que algunas consultas se facilitan y no requieren de realizar operaciones intermedias como un CAST. En algunas consultas uno debe realizar comparaciones con fechas y horas de forma separada, entonces bajo esta premisa nos puede ser útil.
Por ejemplo Si tuviéramos un campo Fecha/Hora y se desea obtener la hora de entrada del personal para comprobar si llegan tarde (nótese que no nos interesa la parte fecha... está sobrando para el caso) uno tendrá que hacer algo como:

sql

SELECT CAST(CampoFechaHora AS TIME)
FROM IngresoPersonal

Pero también puede conducir a redundancia, ya que se está desperdiciando espacio... Se utilizan dos campos cuando se puede trabajar con uno sólo. No interesa si se llena la hora o la fecha. Cuando se lee se recuperan los datos y en caso de estar vacio no se muestra esto.
Además, en ocasiones este diseño farovece a otros tipos de consultas: cuando se debe trabajar tanto con la parte fecha como la hora en conjunto. Por ejemplo, si uno quiere saber la fecha y hora de vencimiento de las comidas refrigeradas para ver si deben ser cambiadas, uno tranquilamente puede hacer algo como:

sql

SELECT FechaVencimiento
FROM Productos
WHERE FechaVencimiento >= '10-11-2010 12:35'

Si tuviéramos dos campos separados tendríamos que hacer algo como:

sql

SELECT FechaVencimiento, HoraVencimiento
FROM Productos
WHERE (FechaVencimiento >= '10-11-2010') AND (HoraVencimiento >= '12:35')

Ambos diseños tienen sus pros y contras. Debe analizarse objetivamente cual te ofrece más facilidades, de todas formas empleando ADO o cualquier otra suite de componentes deberás hacer tratamiento con el tipo TDateTime.

Cuando se leen los campos, todo los campos de fechas y horas internamente se representan con el tipo TDateTime, la única excepción es con el tipo TIMESTAMP, que en Delphi se traduce al TSQLTimeStamp para ADO.
TimeStamp es un tipo de dato Fecha/Hora con un formato especial de almacenamiento y se lo utiliza para casos en los que se requiere de precisión en los cálculos de fecha y hora a una razón, si no me falla la memoria hasta 1/10000 de segundo.

En teoría de normalización de base de datos, no es deseable disponer de un campo para la fecha y otra para la hora. En la práctica se pueden encontrar argumentos para ambos criterios, aunque por lo general para la amplia mayoría de los casos basta con usar el tipo Fecha/Hora. Los castings y las operaciones intermedias no suponen una gran pérdida del rendimiento. Podría argumentarse, allí si con más razón de peso, cuando se espera cantidades muy altas de registros.

Espero que con esto estén más claras las cosas.

Saludos,
                       

[lsedr]

Ok. Bueno, luego de ver la explicación, creo que me es más conveniente usarlo asi.
Acepto sugerencias.

Este es el Diagrama de las tablas que usare.
Se trata de un taller que repara solamente Televisores.

Archivos adjuntos

•  2001_3ed359de665f71a939ed3f5b3bb871294aa444ec.png   16,71KB   10 descargas

[Delphius]

Ok. Bueno, luego de ver la explicación, creo que me es más conveniente usarlo asi.
Acepto sugerencias.

Este es el Diagrama de las tablas que usare.
Se trata de un taller que repara solamente Televisores.

Pues yo considero que es un modelo bastante simple y funcional... siempre y cuando no se intente sacar más de lo que ofrece.

Tendría que conocer con mayores detalles sobre el sistema y los requisitos para hacer un examen más profundo y poder sacar una conclusión más certera.

lsedr debes entender que no se puede inferir una complejidad total de un sistema partiendo desde el DER. Más bien es el DER el que se desprende del sistema. Lo que puedo decirte de lo que veo es que pude funcionar como que no... depende de lo que realmente se necesita llevar a cabo.

En una apreciación conceptual y de reglas normales no hay nada que criticar a ese diseño. De allí en más, inferir si ese DER cumplirá con un "sistema de control de reparaciones" no es totalmente posible. La pregunta del millón es ¿Tienes completamente bien definidos los límites del sistema?

Saludos,

[lsedr]

Pues si amigo Delphius se trata de eso, un sistema sencillo de facil uso que registre clientes y los televisores que ellos desean que el taller les repare. Por eso la relacion entre tablas la hice sencilla.
Pues un cliente nuevo logicamente traera un TV a reparar, y cuando ya quede registrado, pues en otra fecha podra traer mas televisores. Es entonces cuando el sistema controla eso. Pues un cliente puede tener varios televisores a querer reparar, y cada uno de ellos puede que sean iguales, pero hay siempre una caracteristica diferente y es el Serial del televisor. Pues asi cada equipo que se registre automaticamente el sistema le hace una orden de reparacion que se almacena en una tabla llamada Ordenes, y desde ahí el usuario ve cuales equipos estan en 'ordenes de reparacion' y luego los tecnicos del taller van revisando los equipos según el campo 'Orden_No' para ver si es posible repararlos y despues se lo informan al usuario para que indique al sistema en una tabla llamada Reparaciones, si el equipo pudo ser reparado y cual fue la solucion al problema.

Archivos adjuntos

•  2005_2cd8b9ffcb19d0748fc12df631a27bfaf97dc8fd.png   31,18KB   4 descargas

[Delphius]

Hola Isedr,
Te agradezco que te tomaras el tiempo de comentar sobre el escenario que estás evaluando.
Por la descripción que ofreces, y el DER que nos pasaste unos posts antes yo diría que está todo claro y debería funcionar sin problemas. Tu diseño se ajusta muy bien.

Por mi parte no tengo alguna sugerencia u objeción por hacerte. Creo que vas lo suficientemente encaminado como para poder continuarlo tu solo. 

Espero que no te haya molestado la "presión" que te he dado últimamente. Hay cosas que es necesario explorar por uno mismo, y que por más que pudiéramos ofrecerte una respuesta bien completa, profunda, sobre tus dudas no hay nada mejor que verlo por nuestros propios ojos.
Por ello yo buscaba, y buscaré, fomentar la lectura, un análisis de las ideas. Hay que acostumbrarse a pensar y analizar y sobre todo a sentirse seguro de nuestros desarrollos. Que una pregunta como "¿Alguna sugerencia?" no te lleve a sentir inseguridad sobre tu trabajo.
Está bien recibir consejos, alternativas, opciones, guías, etc. Pero a la par debemos ir desarrollando más el aspecto lógico, analítico y todo lo que vayamos leyendo lo empecemos a poner en práctica.

Mi consejo: ármate de paciencia. He visto que has estado muy preguntón  . Eso es bueno, como también malo... Es bueno si luego aprovechamos las respuestas y las bajamos a tierra para analizarlas, estudiarlas. Es malo si nos dejamos vencer por la desesperación y el desorden de ideas porque ello conducirá a que el bosque nos tape el árbol. Aprender programación lleva muuuuuucho tiempo, asi que no desesperes.

Creo que ya vas uniendo mejor las cosas y entiendo como funciona el foro.
Si tienes dudas, aquí estaremos. 

Saludos,