PC Toledo

Achei que tinha resolvido isso, mas não.

Usei

data between cast( '2020-01-01' as date ) and cast( '2020-01-31' as date )

será que falhou porque faltou o cast() em data?

cast( data as date ) between cast( '2020-01-01' as date ) and cast( '2020-01-31' as date )

ou não tem jeito, e tem que fazer de outra forma?

http://sqlfiddle.com/#!2/b4852/4

Stack overflow:
Use o operador BETWEEN para facilitar e converta DATETIME para DATE.

Exemplo:

SELECT titulo
FROM eventos
WHERE '2014-02-01' BETWEEN date(inicio) AND date(fim)
Veja o exemplo no sqlfiddle.

A função date() do MysQL extrai somente a parte da data para ignorar a hora na comparação.


Tentei colar o link do Stack overflow mas não deu certo. Mesmo com tag URL.

São equivalentes, mas Date() parece mais adequada.

https://www.w3schools.com/sql/func_mysql_cast.asp
https://www.w3schools.com/sql/func_mysql_date.asp

CAST( x AS DATE )
DATE( x )

Mesmo assim, ainda deixa dúvida sobre a forma correta de usar:

data between Date( '2020-01-01' ) and Date( '2020-01-01' )

Date( data ) between '2020-01-01' and '2020-01-01'

Date( Data ) between date( '2020-01-01' ) and Date( '2020-01-01' )


Aqui ainda tentando decifrar se o problema realmente tem alguma coisa a ver com data.

No google encontrei exemplos variados, deixando dúvida.

Em uma delas, encontrei Date_Format( Data, '%Y-%m-%d' ) BETWEEN '2020-01-01' and '2020-01-01'

Na dúvida, talvez melhor colocar em todos os elementos envolvidos, até poder confirmar aonde pode remover.

Encontrei o erro.
É uma coisa que preciso rever no aplicativo, porque complica os comandos.
Inverti a comparaçao, e ao invés de pegar a data da nota fiscal, estava pegando a data do pedido.

Aproveitei pra alterar tudo pra DATE() ao invés de CAST().
Funciona igual das duas formas, mas é menos texto usando DATE(), e achei mais adequado usar a função que extrai data sem horário ao invés de uma função que converte qualquer coisa pra data.

de CAST( DATA AS DATE ) para DATE( DATA )

Talvez eu nem precisasse nenhuma conversão, porque os campos são DATE.
O interessante disso é que se eu alterar os campos DATE pra DATETIME, vai estar tudo pronto.

Pra quem não acompanha o Harbour, existe esse tipo nele.
É um tipo que armazena data/hora numa mesma variável/campo.
Mais prático do que usar variável/campo separado pra isso.

Por exemplo, ao invés de armazenar apenas a data de emissão, pode armazenar data e hora, só trocando o campo de DATE pra DATETIME.

E por falar nisso.... com tanto recurso do MySQL....
Dá pra oferecer pro cliente uma análise por horário, por dia da semana, etc. expandindo as análises do aplicativo.
Basta usar recursos do servidor/MySQL, ajustando o comando, sem ficar criando rotinas quilométricas pra isso.

Pois é....
E a gente pensando que a vantagem era só índices "não corrompidos", e uso remoto...

Pra quem não está acostumado: não considere nada do outro mundo.
É algo até conhecido, o IIF()

conhece este?
é equivalente a este:
que se for SET RELATION simplifica:
E no caso do MySQL, é testar NULL, que significa que não encontrou nada (porque foi relacionado também)
Ou seja, praticamente tudo do mesmo jeito.
o SQL é praticamente um "dBASE" que evoluiu, e ficou incorporado ao servidor.
E dBase... é com a gente mesmo !!!!
É voltar ao passado... ao futuro do passado.

Talvez até quem começou no tempo do dBASE tenha mais facilidade, porque o dBASE realmente era como um servidor SQL local.
Só não dava pra usar pelo aplicativo.....

Lógico, aproveitei pra mexer mais no comando.
Ao invés de agrupar por ano,mes ou format( data, '%Y-%m' ), agrupei por LAST_DAY(), que equivale ao último dia do mês da data.
Ao fazer isso, está agrupado por mês, sem complicações extras.