Conversao Campos Alfa para Date

[Laudelino Scarmagnani]

Boa noite, pessoal.
Tenho um campo Caracter 20150307.
Quero gravá-lo num campo tipo Date num arquivo .dbf. Como faço isso?
Laudelino

[lugab]

dd=strzero(val(substr(campomemo,1,2)),2)
mm=strzero(val(substr(campomemo,3,2)),2)
aa=strzero(val(substr(campomemo,5,4)),4)

Repl campodbf with ctod(dd+"/"+mm+"/"+aa)

[alxsts]

Olá!

Veja:

Código: Selecionar todos

#include "set.ch"

FUNCTION Main()

   LOCAL cString    As Character
   LOCAL dDate      As Date
   LOCAL dtDateTime As DateTime      

   SetMode( 25, 80 )
   
   Set( _SET_DATEFORMAT, "dd/mm/yyyy" )
   
   CLS
   
   cString := DtoS( Date() )
   
   dDate := CtoD( Right( cString, 2 )  + "/" + Substr( cString, 5,2 ) + "/" + Left( cString, 4 ) )
 
   dtDateTime := DateTime()
   
   ? "   Data para String       ---> ", cString
   ? "   String para Data       ---> ", dDate
   ? "   Data e hora do sistema ---> ", dtDateTime
   ?
   ?
   
   RETURN NIL

// Resultado:


  Data para String       --->  20150309
  String para Data       --->  09/03/2015
  Data e hora do sistema --->  09/03/2015 23:05:10.189

[ANDRIL]

Tenho um campo Caracter 20150307

Não uso campo DATE nos meus DBFs a muito tempo, devido o ano ter apenas 2 digitos. Não sei se o comando SET DATE TO, SET CENT ON e o SET EPOCH TO afetam o tamanho e formato do campo no dbf, mais segue meu exemplo:

Código: Selecionar todos

cDate="20150307"
dia = left(cDate,2)
mes = substr(cDate,5,2)
ano = substr(cDate,3,2)

replace CMPDATE with ctod(dia+"/"+mes+"/"+ano)  //   07/03/15

Ate+

[Eolo]

Não uso campo DATE nos meus DBFs a muito tempo, devido o ano ter apenas 2 digitos. Não sei se o comando SET DATE TO, SET CENT ON e o SET EPOCH TO...

Andril,

Em DBFs, campos DATE têm SEMPRE 8 dígitos e o formato AMERICAN: AAAAMMDD.

Os comandos e funções que limitam o ano a dois dígitos ou mudam o seu formato, são somente para EXIBIÇÂO.

Por exemplo, SET DATE BRITISH mostra datas no formato DDMMAAAA ou DDMMAA, mas elas continuam gravadas, no DBF, no formato AAAAMMDD.

Anexo "raio-X" de um DBF...

[ANDRIL]

Eolo, obrigado pela explicação! Como disse, nunca fui adepto do uso de campos DATE no DBF. Isso força o uso SET EPOCH TO para definir a época do ano. Antes da virada do ano 2000, já tinha optado definitivamente por campos caracteres para armazenamento das datas com anos de 4 digitos, embora ocupem mais espaço em disco.

Ate+

[Eolo]

Eu fiz diferente: desde sempre usei datas com AAAA, seja em SAY, GET, Browse etc.

Ainda no Summer, tentei usar o SET EPOCH com o SET CENT OFF, mas confesso que não consegui.

Se vc tem um DBF com datas dentro de um intervalo pequeno, digamos 1990 a 2015, fica fácil cercar. Mas e se for um cadastro de nomes com data de NASCIMENTO, contendo gente que nasceu em 1915 e 2015?... O que vai ser gravado nos dois registros, baseado no SET EPOCH definido?

Usando 8 dígitos, fim de qualquer problema em qualquer situação.

[ANDRIL]

Usando 8 dígitos, fim de qualquer problema em qualquer situação

Não seriam 10 digitos (2015/03/10)?

contendo gente que nasceu em 1915 e 2015

Justamente poi isso citei o epsódio do ano 2000 (Bug do Milênio), onde sistemas que tinham seus campos de datas com ano de 2 dígitos tiveram que serem ajustados as pressas. No meu caso, passou despercebido por que meus sistemas já trabalhavam com datas com anos de 4 dígitos.

Ate+

[Eolo]

Não seriam 10 digitos (2015/03/10)?

Os "/s" são só pra exibição, não são guardados no DBF. Lá dentro, é 20150310. Tanto que vc pode alterar a exibição para "2015-03-10" (ou outros).

Quando vc usa o DbCreate, por exemplo, na matriz dos campos vc faz aadd(estrutura, {"DATA", "D", 8, 0}). É 8 e não 10.

Sobre o bug do milênio, acredito que sistemas grandes, pra economizar espaço em disco, até então guardavam datas com AA mas, na virada do século, tiveram que se virar e passar pra AAAA. Pro Summer e DBF, não tinha bug nenhum e eu, então, não tive que alterar nada em meus programas.

[ANDRIL]

Eolo, vendo o print acima, nota-se que a data esta somente com os números. Meu desapego ao campo date é tanto que só agora notei isso. Como sempre uso DBU para editar os DBFs e nele o campo esta formatado " 00/00/00" nem me dei conta que era apenas na exibição. Abraço!

Ate+

[Laudelino Scarmagnani]

Olá Eolo, Grande abraço! Estás sumido!
Quanto ao campo tipo Date, no DBF, é interessante pela necessidade de calculo das datas, numero de dias, etc. Fica automático. Se o mantermos em formado numérico ou carácter, teremos que desenvolver as rotinas para estes cálculos. Quanto ao problema do ano base, para conversão automática ao demonstrar as datas, existe em várias linguagens. Trabalho com Cobol 74 e temos este problema, apesar das datas estarem em formato CCYYMMDD no Banco de Dados. Aí´é uma solução para cada caso.
Laudelino