TRATAMENTO DE DATA PARA ARMAZENAMENTO EM BD
Ao armazenar uma data (ex: 11/03/04) em uma variável e exibi-la, o VB (meu alicativo) exibi 11/03/2004, ou seja, passa de 8 posições para 10 automaticamente. Porém, ao tentar armazená-la no Access em um campo data que corresponde a 8 posições logicamente dá erro...
Goataria de saber como posso resolver este problema, se alguém teria uma sugestão para me ajudar ?!
Obrigado desde já.
Goataria de saber como posso resolver este problema, se alguém teria uma sugestão para me ajudar ?!
Obrigado desde já.
Veja, independente da forma como você apresente, qualquer campo data do MS-Access® sempre mantém informações relativas á dia, mês, ano, hora, minuto e segundo e ainda, internamente, o formato de armazenamento é o de padrão Americano, ou seja, "MM/DD/YYYY". Isto significa que será mostrado neste formato? Não, a forma como um campo data será apresentado depende da configuração do ambiente (MS-Windows®) e do formato definido para o campo, na aplicação que o utiliza, seja ele o MS-Access ou seu aplicativo. Para que seu campo data se apresente com um formato especÃfico, em sua aplicação, você poderá se utilizar da função Format/Format$ e de máscaras de formatação. Essas máscaras podem ser:
- Format$("11/03/04", "Short Date" ) - Depende do formato de seu sistema, mas mostrará a data de forma "resumida", como em "11/03/04", na aplicação.
- Format$(Now, "Long Date" ) - Depende do formato de seu sistema, mas mostrará a data de forma "extendida", como em "quinta-feira, 11 de março de 2004", na aplicação.
- Format$("11/03/04","HH:nn:SS") - Mostrará a data como horas, apenas, como em "00:00:00", na aplicação.
- Format$("11/03/04","dd/MM/YY") - Mostrará a data como você definir, como em "11/03/04", na aplicação.
- Format$("11/03/04","dd/MMM/YY") - Mostrará a data como você definir, como em "11/MAR/04", na aplicação.
- Format$("11/03/04","dd/MMM/YYYY") - Mostrará a data como você definir, como em "11/MAR/2004", na aplicação.
- Format$("11/03/04","MMMM HH:nn:SS") - Mostrará a data como horas, apenas, como em "MARÇO 00:00:00", na aplicação.
E por aà segue.
Ao abrir com o Access, por outro lado, mesmo que sua aplicação mostre a data das formas acima apresentadas, os formatos estarão sendo apresentados de forma distinta, em acordo com a propriedade Format do campo e/ou com o formato do sistema operacional. Ainda, internamente, o formato será sempre o Americano. Por esse motivo, para selecionar um certo registro por meio de um campo data, o correto para bases MS-Access é utilizar esse formato na instrução SQL, como, por exemplo: "SELECT * FROM CLIENTES WHERE CLIENTES.NASCIMENTO = #" & Format$( txtNascimento.Text, "MM/DD/YY") & "#;"
Outro detalhe importante é que ao determinar o formato de um campo data NA CRIAÇÃO da tabela, se você salvar uma data inteira (por exemplo, utilizando Now na atribuição do campo), a hora será gravada e nas seleções ela também será levada em conta. Assim, um campo data atribuido como Now, ás 16:24, será armazenado como #03/11/2004 16:24:32# e ao selecionar "SELECT * FROM CLIENTES WHERE CLIENTES.NASCIMENTO = #03/11/2004#;" esse registro não aparecerá.
Também há outro detalhe sobre os campos data do Access, SQL Server e MSDE (Microsoft), Interbase (Borland) e MySQL, que deve ser pensado: A indexação desse tipo de campo é bem mais complexa, portanto mais lenta e o consumo de recursos é maior do que, por exemplo, um campo longo. Assim, com um pouco mais de trabalho, pode-se utilizar um campo do tipo Longo, armazenando não a data, mas a data em formato serial, o que torna o desempenho sensivelmente melhor, quanto maior for a tabela. No caso de engines como o Oracle, os Ãndices para esse tipo de campo também demoram mais, mas o desempenho do engine compensa.
Acabei fugindo um pouco do assunto, mas, para resumir, procure sempre formatar as datas antes de armazená-las e assim que recuperá-las da base de dados. Isso deve minimizar seus problemas. E para os DataGrid e DBGrid, cada coluna possui uma propriedade NumberFormat, para a qual você pode também definir uma máscara (como as vistas aqui, antes), para não "ter surpresas" na apresentação dos dados.
Valew?
- Format$("11/03/04", "Short Date" ) - Depende do formato de seu sistema, mas mostrará a data de forma "resumida", como em "11/03/04", na aplicação.
- Format$(Now, "Long Date" ) - Depende do formato de seu sistema, mas mostrará a data de forma "extendida", como em "quinta-feira, 11 de março de 2004", na aplicação.
- Format$("11/03/04","HH:nn:SS") - Mostrará a data como horas, apenas, como em "00:00:00", na aplicação.
- Format$("11/03/04","dd/MM/YY") - Mostrará a data como você definir, como em "11/03/04", na aplicação.
- Format$("11/03/04","dd/MMM/YY") - Mostrará a data como você definir, como em "11/MAR/04", na aplicação.
- Format$("11/03/04","dd/MMM/YYYY") - Mostrará a data como você definir, como em "11/MAR/2004", na aplicação.
- Format$("11/03/04","MMMM HH:nn:SS") - Mostrará a data como horas, apenas, como em "MARÇO 00:00:00", na aplicação.
E por aà segue.
Ao abrir com o Access, por outro lado, mesmo que sua aplicação mostre a data das formas acima apresentadas, os formatos estarão sendo apresentados de forma distinta, em acordo com a propriedade Format do campo e/ou com o formato do sistema operacional. Ainda, internamente, o formato será sempre o Americano. Por esse motivo, para selecionar um certo registro por meio de um campo data, o correto para bases MS-Access é utilizar esse formato na instrução SQL, como, por exemplo: "SELECT * FROM CLIENTES WHERE CLIENTES.NASCIMENTO = #" & Format$( txtNascimento.Text, "MM/DD/YY") & "#;"
Outro detalhe importante é que ao determinar o formato de um campo data NA CRIAÇÃO da tabela, se você salvar uma data inteira (por exemplo, utilizando Now na atribuição do campo), a hora será gravada e nas seleções ela também será levada em conta. Assim, um campo data atribuido como Now, ás 16:24, será armazenado como #03/11/2004 16:24:32# e ao selecionar "SELECT * FROM CLIENTES WHERE CLIENTES.NASCIMENTO = #03/11/2004#;" esse registro não aparecerá.
Também há outro detalhe sobre os campos data do Access, SQL Server e MSDE (Microsoft), Interbase (Borland) e MySQL, que deve ser pensado: A indexação desse tipo de campo é bem mais complexa, portanto mais lenta e o consumo de recursos é maior do que, por exemplo, um campo longo. Assim, com um pouco mais de trabalho, pode-se utilizar um campo do tipo Longo, armazenando não a data, mas a data em formato serial, o que torna o desempenho sensivelmente melhor, quanto maior for a tabela. No caso de engines como o Oracle, os Ãndices para esse tipo de campo também demoram mais, mas o desempenho do engine compensa.
Acabei fugindo um pouco do assunto, mas, para resumir, procure sempre formatar as datas antes de armazená-las e assim que recuperá-las da base de dados. Isso deve minimizar seus problemas. E para os DataGrid e DBGrid, cada coluna possui uma propriedade NumberFormat, para a qual você pode também definir uma máscara (como as vistas aqui, antes), para não "ter surpresas" na apresentação dos dados.
Valew?
Tópico encerrado , respostas não são mais permitidas