Reading time: 6 minutes
Ás vezes, trabalhar om datas no Access requer um pouco de paciência por parte do usuário. Isto tudo por causa dos formatos em diferentes nacionalidades.
Neste artigo trago algumas particularidades ao se trabalhar com Datas aqui no Access. Saliente que ele foi escrito faz muito tempo, pelo amigo Osmar José Correia Júnior membro do site AtivoAccess
Como trabalhar com DATAS no Access
Datas Internacionais no Access
Nos EUA eles formatam a data como mm/dd/yy. Os países da comunidade britânica (e latina) usam dd/mm/yy.
Na Coréia e outros países orientais é usado yy/mm/dd.
Em alguns países, os separadores de data são pontos ou traços, não barras.
Se você vive fora dos Estados Unidos, ou desenvolve aplicações que serão utilizadas em outros países, deve saber como tratar datas no Access.
Quando você digita uma data no Access, sua entrada é armazenada como um número, onde a parte integral representa a data e a parte fracionária representa a hora (parte do dia). As coisas podem dar errado em três pontos:
- O Access interpreta erradamente uma entrada de data;
- Você deixa de formatar corretamente a data no código;
- O Access não sabe que uma entrada deve ser interpretada como uma data.
Interpretação Errada da Interface do Usuário
Defina o formato da data no Painel de Controle | Opções regionais do Windows.
Desta forma você pode usar o formato local de datas na entrada de dados na interface do usuário do Access: tabelas, consultas, formulários ou como critério na Estrutura de consultas.
A Microsoft tentou ser muito inteligente fazendo o Access ajudar ao aceitar datas.
Se você entrar com uma data que é inválida para sua opção de formato, o Access “trabalha” a data tentando encontrar uma interpretação que funcione.
Por exemplo, com datas no formato britânico no Painel de Controle, se a entrada for 10/13/01, o Access vê que não existe um 13* mês, e decide que o que você queria dizer era 13-Out-01.
Os resultados podem ser bizarros. Uma entrada 02/29/01 deveria gerar uma mensagem de erro, já que 2001 não é um ano bissexto. Não gera. Em vez disso, o Access trabalha a data e decide que você pretendia digitar Fev-01-2029!!!
Tirando esta loucura (que não pode ser desativada), lembre-se que a interface de usuário do Access usa as opções do Painel de Controle para tratar as datas digitadas na interface.
Formatação Errada no Código
No código VBA, delimita-se a data com o símbolo “#”. Nas versões 32 bits do Acces estas entradas devem seguir o formato americano, não importando as opções regionais, p/ex. #12/31/199#. O velho Access Basic (Versões 1 e 2) seguiam as opções do painel de controle, assim sendo, tome cuidado se estiver trabalhando com versões mais antigas ou convertendo programas destas versões.
Em todas as versões do Access (inclusive as 16 bits), o SQL JET exige que as datas estejam no formato americano. Para demonstrar isto, entre com qualquer data como critério em um campo de uma consulta no modo estrutura e passe para o Modo SQL. Na estrutura a data está no formato da opção regional, mas o comando SQL gerado está no formato mm/dd/yy.
As cláusulas SQL nem sempre são óbvias, p/ex. o Filtro de um formulário, a Condição Where de um OpenReport, ou como terceiro argumento de uma função de domínio agregado. Exemplos:
DoCmd.OpenReport "MyReport", acViewPreview, , "InvoiceDate > #12/31/2000#"
Debug.Print DLookup("StudentID", "tblStudent", "EntryDate = #6/30/1953#")
strSQL = "SELECT * FROM tblDonation WHERE DonationDate > #" & Format(Me.StartDate, "mm\/dd\/yyyy") & "#;"
O terceiro exemplo demonstra como concatenar uma data em uma string SQL. A função Format é essencial para forçar a data para o formato americano. Por azar, Format() substitui as barras pelos caracteres separadores definidos nas Opções regionais do Painel de Controle, portanto devemos especificar barras literais na string de formatação precedendo a barra com uma barra invertida.
Como isto é uma coisa muito usada, poderia ser usada uma função bem simples para concatenar strings de datas:
Function SQLDate(varDate As Variant) As String
If IsDate(varDate) Then
SQLDate = "#" & Format$(varDate, "mm\/dd\/yyyy") & "#"
End If
End Function
Tipo de Data Não Reconhecido
Existem dois casos onde o Access pode não entender a entrada como uma data.
Controles Desvinculados
Caixas de texto vinculadas a campos Data não são problema, mas se o controle é desvinculado (nada na sua propriedade Origem do Controle), como o Access pode saber qual o tipo de dados desejado? Se você estiver nos EUA, provavelmente vai ser entendido corretamente. Se for usado um outro formato de data, há uma grande probabilidade de que a data vai ser interpretada de forma errada.
Em geral, a propriedade Formato do controle tem a ver com a forma com que o Access mostra o dado e não controla a entrada de dados. Entretanto, se o formato for Data Abreviada ou similar, o Access é incapaz de formatar uma data inválida, fazendo com que apenas datas válidas sejam inseridas.E como o Access sabe o tipo de dado, as interpretações erradas desaparecem.
Simples como possa parecer, acertar a propriedade Formato é o bastante para forçar o Access a reconhecer o tipo de dados de controles desvinculados.
Campos de Data Calculados
O Access também pode interpretar erroneamente campos de data calculados em consultas, especialmente se o formato de data não é o americano e o campo contiver alguns Nulos. Os sintomas óbvios são de que os campos são alinhados à esquerda e clasificados como strings.
A solução para isto é tipar explicitamente todos os campos de data calculada, por exemplo:
DataFim = CVDate(DataInicio + 30)
Nota: CDate() dá erro em valores nulos, portanto CVDate() tem mais utilidade do que a simples “compatibilidade” apresentada na documentação do Access.
Com estas dicas simples você pode criar bases de dados que podem ser utilizadas em qualquer lugar, mesmo que o formato de data do usuário seja diferente da sua.
Espero que você tenha gostado desta dica e caso este artigo fez sentido para você, compartilhe para que outros usuários possam aprender também.
E caso tenha alguma dúvida, não hesite em colocar nos comentários aqui abaixo, blz?
Até o próximo artigo!
Aldir Oliveira
