DCount ignorando algumas datas

[wandersar]

Tenho uma tabela que é acessada através de um formulário. O campo data do formulário, antes de ser atualizado, checa se a data inserida já está cadastrada. O resultado é o esperado, porém, algumas datas passar batido. Como se o código as ignorasse. Funciona normalmente com a maioria das datas, mas, com algumas, é como se elas simplesmente não tivesse cadastradas.



Private Sub cli_nome_BeforeUpdate(Cancel As Integer)


If DCount("*", "tbl_clientes", "cli_data=#" & Me.cli_data & "#") <> 0 Then 'se fosse texto, ao invés de #s, 's é que seriam usadas
MsgBox "a data " & Me.cli_data & " já tem", vbInformation, "Atenção"
Cancel = True
End If


End Sub

[CJ_London]

Translated

I have a table that is accessed through a form. The form date field, before being updated, checks if the date entered is already registered. The result is as expected, however, some dates pass beaten. As if the code ignored them. It works normally with most dates, but

what does ‘some dates pass beaten’ mean?

I suspect you mean that a date like 13/07/2024 passes, But a date like 12/07/2024 doesn’t. Provide some example dates that pass and some that don’t

[Welshgasman]

Try a format.

'Public Const strcJetDate = "\#mm\/dd\/yyyy\#"  'Needed for dates in queries as Access expects USA format.
Public Const strcJetDate = "\#yyyy-mm-dd\#"  'Needed for dates in queries as Access expects USA but will accept ISO format.

[wandersar]

[CITAÇÃO=CJ_London; 526568]Traduzido



, o que significa 'algumas tâmaras passam batidas'?

Eu suspeito que você quer dizer que uma data como 13/07/2024 passa, mas uma data como 12/07/2024 não. Forneça alguns exemplos de datas que passam e outras que não [/ QUOTE]


'Algumas tâmaras passam batidas' ... significa que umas o código "conta", percebe a duplicidade. E outras, não.

Exemplos: 21/11/1979 o código avisa se duplicado. O mesmo acontece com 12/12/1980, 15/09/2024, 10/10/2024. Já as datas 07/08/2020, 09/08/2021, 08/06/2020, 08/06/2022 ... aliás, 08/06, não importa o ano. Todos ficam fora da contagem e são duplicados.

[Welshgasman]

Sorry, I am not going to translate what you post all the time. That is for you to do.
This is an English Access site after all.

[CJ_London]

Because you are creating a sql string, as welshgasman suggests, you need to use the format function to format the date into something that sql understands.

The # characters tell sql to treated whatever is between them as a date

Sql understands dates in the format yyyy-mm-dd (the sql standard) or the US format of mm/dd/yyyy or if the date is unambiguous, such as dd mmm yyyy

For example

"12/12/1980" is the same - 12th December either way, so not ambiguous

"07/08/2020" (which you see as 7th August) is ambiguous because it is viewed by sql as 8th July

However
"21/11/1979" is not ambiguous because there are not 21 months in the year and sql know enough to swap the day and month around

"05 Aug 2024" is not ambiguous because the month is spelt rather than identified as a number

Personally I favour using the sql standard of yyyy-mm-dd

It is more work for developers who do not use US dates but it just makes the US developers lazy and they get a bit of a shock when their app is subsequently used in a region that does not use US dates

[wandersar]

Sorry! I'm new here. I hadn't paid attention to that.

[wandersar]

Thank you very much!

[wandersar]

Obrigado!

[CITAÇÃO=CJ_London; 526580]Como você está criando uma string sql, como welshgasman sugere, você precisa usar a função format para formatar a data em algo que o sql entenda.

Os caracteres # dizem ao sql para tratar o que quer que esteja entre eles como uma data

Sql entende datas no formato aaaa-mm-dd (o padrão sql) ou no formato americano de mm/dd/aaaa ou se a data não for ambígua, como dd mmm aaaa

Por exemplo

, "12/12/1980" é o mesmo - 12 de dezembro de qualquer maneira, portanto, não é ambíguo

"07/08/2020" (que você vê como 7 de agosto) é ambíguo porque é visto pelo sql como 8 de julho

No entanto,
"21/11/1979" não é ambíguo porque não há 21 meses no ano e o sql sabe o suficiente para trocar o dia e o mês em torno de

"05 de agosto de 2024" não é ambíguo porque o mês é escrito em vez de identificado como um número

Pessoalmente, sou a favor de usar o padrão sql de aaaa-mm-dd

É mais trabalhoso para desenvolvedores que não usam datas dos EUA, mas apenas torna os desenvolvedores dos EUA preguiçosos e eles ficam um pouco chocados quando seu aplicativo é usado posteriormente em uma região que não usa datas


dos EUA [/ QUOTE]