none
Problema com datas no SQL Server 2005 + C# RRS feed

  • Pergunta

  • Galera, não sei se estou postando na sala correta, mas efim... é o seguinte: estou fazendo um programa em C# com base de Dados SQL Server 2005.

    Porém estou tendo problema com as datas...

    a) Quando tento fazer um insert, ele diz que a data está fora dos limites... Pesquisei na net e fala que o formato padrão do SQL Server é MM/DD/AAAA. Não tem como mudar esse padrão, ou resolver o problema de alguma outra forma que não seja tratar a data que estou inserindo, pois o software usa o padrão DD/MM/AAAA.

    b) Quando faço um select, ele num me retorna DD/MM/AAAA, mas sim D/M/AAAA... Ou seja, se tiver armazenado 01/01/2000, ele retorna 1/1/2000... Num tem como mudar isso não?

    Obrigado pela ajuda de todos...
    quinta-feira, 15 de maio de 2008 13:57

Respostas

  • Olá,

     

    É possível que você altere algumas configurações para que o SQL Server comece a pensar em um formato diferente. Você pode por exemplo mudar o Default Language de seu Login para português e dessa forma o formato de data será sempre DD/MM/YYYY para aquele Login.

     

    Outra alternativa é usar a instrução SET DATEFORMAT DMY e nesse caso enquanto durar a sessão, o formato será DD/MM/YYYY (se utilizada dentro de SP, essas configurações só duram enquanto a SP é executada).

     

    Ainda assim creio que YYYYMMDD é a melhor saída. Qualquer outra solução deixará sua aplicação presa a configurações e no caso do SET DATEFORMAT dentro de SPs força uma recompilação retardando seu desempenho.

     

    O CONVERT não perde desempenho se usado na cláusula SELECT. Ex:

     

    SELECT CONVERT(CHAR(10),Data,103) FROM Tabela.

     

    Ele perde desempenho se usado no WHERE. Ex:

     

    SELECT * FROM Tabela WHERE CONVERT(CHAR(10),Data,103) = 'dd/mm/yyyy'

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 15 de maio de 2008 17:28

Todas as Respostas

  • 1°) Esse site abaixo soluciona o suas dúvidas com data
    http://www.sql-server-helper.com/tips/date-formats.aspx

    2°) SET DATE FORMAT TO "DD/MM/YYYY"

    3°) Está usando C# com webForms ?
    Caso sim:

    Coloque isso no seu webConfig

    quinta-feira, 15 de maio de 2008 14:10
  • Olá Flávio,

     

    Você pode procurar nos outros posts e encontrará diversas mensagens sobre problemas com datas e possíveis soluções. Por hora, grave as datas no formato YYYYMMDD (sem barras ou hífens) e não terá problemas.

     

    Para exibir a data no formato DD/MM/YYYY, use CONVERT(CHAR(10),Data,103). Essa condição só deve ser usada na cláusula SELECT. Não use essa construção em cláusulas WHERE (pode levar a perda de desempenho). Na cláusula WHERE use YYYYMMDD

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 15 de maio de 2008 14:13
  • Code Snippet

     Gustavo Maia Aguiar wrote:

    Olá Flávio,

     

    Você pode procurar nos outros posts e encontrará diversas mensagens sobre problemas com datas e possíveis soluções. Por hora, grave as datas no formato YYYYMMDD (sem barras ou hífens) e não terá problemas.

     

    Para exibir a data no formato DD/MM/YYYY, use CONVERT(CHAR(10),Data,103). Essa condição só deve ser usada na cláusula SELECT. Não use essa construção em cláusulas WHERE (pode levar a perda de desempenho). Na cláusula WHERE use YYYYMMDD

     

    [ ]s,

     

    Gustavo

     




    Obrigado pela ajuda de todos.


    A aplicação não é WebForm não... É Windows Application mesmo...


    Tipo assim... Eu estou usando stored procedures... Aí a minha procedure tem o seguinte código...


    Code Snippet

    SELECT * from Titulares Where Cod_Titular = @cod_titular.




    Mas como foi dito, isso geraria perda de desempenho para usar o convert...?

    Outra coisa... Para usar o convert nesse caso, teria que mudar a procedure né... tipo, tirar o * e colocar campo por campo.


    Já para gravar, eu tenho na aplicação um MaskedTextBox... Aí para inserir no BD (de acordo com a solução proposta), eu teria que tratar essa data... O que eu queria saber é se existe um modo mais simples, tipo mudar o padrão mesmo do SQL Server... Como tenho pouca experiência, gostaria de saber exatamente o que é mais usual nesse caso...

    Obs.: Já achei vários tópicos muito úteis sobre isso no fórum... Mas mesmo assim, gostaria da opinião de vocês.

    Valeu.
    quinta-feira, 15 de maio de 2008 16:39
  • Olá,

     

    É possível que você altere algumas configurações para que o SQL Server comece a pensar em um formato diferente. Você pode por exemplo mudar o Default Language de seu Login para português e dessa forma o formato de data será sempre DD/MM/YYYY para aquele Login.

     

    Outra alternativa é usar a instrução SET DATEFORMAT DMY e nesse caso enquanto durar a sessão, o formato será DD/MM/YYYY (se utilizada dentro de SP, essas configurações só duram enquanto a SP é executada).

     

    Ainda assim creio que YYYYMMDD é a melhor saída. Qualquer outra solução deixará sua aplicação presa a configurações e no caso do SET DATEFORMAT dentro de SPs força uma recompilação retardando seu desempenho.

     

    O CONVERT não perde desempenho se usado na cláusula SELECT. Ex:

     

    SELECT CONVERT(CHAR(10),Data,103) FROM Tabela.

     

    Ele perde desempenho se usado no WHERE. Ex:

     

    SELECT * FROM Tabela WHERE CONVERT(CHAR(10),Data,103) = 'dd/mm/yyyy'

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 15 de maio de 2008 17:28

  • Olá,

     

    É possível que você altere algumas configurações para que o SQL Server comece a pensar em um formato diferente. Você pode por exemplo mudar o Default Language de seu Login para português e dessa forma o formato de data será sempre DD/MM/YYYY para aquele Login.

     

    Outra alternativa é usar a instrução SET DATEFORMAT DMY e nesse caso enquanto durar a sessão, o formato será DD/MM/YYYY (se utilizada dentro de SP, essas configurações só duram enquanto a SP é executada).

     

    Ainda assim creio que YYYYMMDD é a melhor saída. Qualquer outra solução deixará sua aplicação presa a configurações e no caso do SET DATEFORMAT dentro de SPs força uma recompilação retardando seu desempenho.

     

    O CONVERT não perde desempenho se usado na cláusula SELECT. Ex:

     

    SELECT CONVERT(CHAR(10),Data,103) FROM Tabela.

     

    Ele perde desempenho se usado no WHERE. Ex:

     

    SELECT * FROM Tabela WHERE CONVERT(CHAR(10),Data,103) = 'dd/mm/yyyy'

     

    [ ]s,

     

    Gustavo




    Cara, obrigado mesmo... Esclareceu bacana...

    Já que você tocou no assunto de recompilar a SP, me gerou mais uma dúvida...

    Nas opções de criação ("With"), existe a Recompile.

    Você disse que recompilar a SP gera perda de rendimento? No caso, se usar essa opção Recompile, haverá perdas de rendimento?


    Valeu mesmo.
    quinta-feira, 15 de maio de 2008 18:07
  • Olá Flávio,

     

    Esse é um tópico mais extenso e penso que não deveríamos extendê-lo nesse post já que recompilação de SPs é um assunto a parte em relação ao post original. Por hora, posso dizer nesse post é que opções como SET DATEFORMAT forçam a recompilação e que na esmagadora maioria das situações, uma recompilação leva a perda de desempenho. Isso inclui a cláusula RECOMPILE. Claro que essa cláusula tem sua importância, mas se for o caso, podemos falar dela em um outro post ou procurar nos posts anteriores.

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 15 de maio de 2008 19:03
  •  Gustavo Maia Aguiar wrote:

    Olá Flávio,

     

    Esse é um tópico mais extenso e penso que não deveríamos extendê-lo nesse post já que recompilação de SPs é um assunto a parte em relação ao post original. Por hora, posso dizer nesse post é que opções como SET DATEFORMAT forçam a recompilação e que na esmagadora maioria das situações, uma recompilação leva a perda de desempenho. Isso inclui a cláusula RECOMPILE. Claro que essa cláusula tem sua importância, mas se for o caso, podemos falar dela em um outro post ou procurar nos posts anteriores.

     

    [ ]s,

     

    Gustavo

     




    OK cara... Valeu mesmo...

    Desculpe aí a inconveniência.

    Até qualquer hora dessas.
    quinta-feira, 15 de maio de 2008 19:06
  • Olá Flávio,

     

    Fique à vontade. É que evitamos posts muito longos e com assuntos misturados senão eles não acabam nunca e dificultam as buscas posteriores além de desmotivar que outras pessoas entrem para responder (não é muito convidativo entrar em um post com muitas respostas. Dá a impressão de já estar encaminhado).

     

    [ ]s,

     

    Gustavo

     

    quinta-feira, 15 de maio de 2008 19:37