Salve,
personalmente riscontro delle problematiche con i tuoi dati...
relativamente alla parte SQL Server, eseguendo il codice di sotto su SQL Server 2014, con impostazioni di lingua per la login in en-US
SELECT @@LANGUAGE;
GO
SELECT CONVERT(date, '20200213')
, CONVERT(date, '20200302')
, CONVERT(date, '02132020')
, CONVERT(date, '03022020');
GO
SELECT CONVERT(date, '20200213')
, CONVERT(date, '20200302')
, CONVERT(date, '02-13-2020')
, CONVERT(date, '03-02-2020')
ottengo:
----------------------
us_english
(1 row(s) affected)
---------- ---------- ---------- ----------
Msg 241, Level 16, State 1, Line 3
Conversion failed when converting date and/or time from character string.
---------- ---------- ---------- ----------
2020-02-13 2020-03-02 2020-02-13 2020-03-02
quindi come vedi, la localizzazione per le date e' legata alla locale americana
il primo comando con la formattazione senza "-" mi solleva eccezioni nella conversione, e per questo solitamente utilizzo il formato con separazione "-", quindi "xx-xx-xxxx";
scrivo "genericamente" xx in quanto non voglio qui fornire indicazioni sul formato specifico di data...
questo perche', per buona prassi, al di la' della localizzazione della login, e' sempre preferibile passare le date in formato ISO "yyyy-MM-dd", formato SEMPRE riconoscibile e riconosciuto, non suscettibile di "interpretazione" e sempre corretto e validato.
tornando allo script di cui sopra, dopo la correzione dell'eccezione, guardiamo cosa succede con i valori
, CONVERT(date, '02-13-2020')
, CONVERT(date, '03-02-2020')
il primo dei 2 viene ovviamente correttamente interpretato, in quanto non e' ovviamente possibile avere un mese = 13, e la data viene parsata e interpretata come: 2020-02-13
il valore successivo, CONVERT(date, '03-02-2020'), con impostazione americana, viene letto anche questo come MM-dd-yyyy, quindi 2 marzo 2020...
e potrebbe NON essere il risultato desiderato... motivo quindi addizionale di utilizzare sempre una formattazione NON interpretabile, quindi "yyyy-MM-dd", che ripeto, NON e' interpretabile diversamente da quanto specificato...
relativamente alla parte applicativa, ti sconsiglio vivamente di passare codice dinamico con parametri gia' valorizzati tipo
CMD.CommandText = "Select * from dbo.persone WHERE (Data_Nascita >= '20200213' and Data_Nascita =< '20200302')
e' sempre buona norma, sia per impedire problematiche di SQLinjection che per semplificare la valorizzazione dei parametri utilizzare SEMPRE un comando con parametri non "inline" ma aggiunti alla collection dei parameters dell'oggetto command...
questo di aiuta anche in quanto e' direttamente l'oggetto parameter caricato con il "valore di tipo date" preso ad esempio dalla tua conversione
.... DateAdd(DateInterval.Day, +1, CDate(CasellaTesto1.Text))
ad occuparsi del caricamento del "valore" in maniera trasparente e dipendente dalla locale "applicativa", in quanto CDATE utilizza la locale corrente e cerca di convertire il testo in una "data", dopodiche' l'operazione di DateAdd semplicemente utilizza tale valore nella sua finestra funzionale...
comunque, ripeto, MAI usare
CMD.CommandText = "Select * from dbo.persone WHERE (Data_Nascita >= '" & dataIniziale & "' and Data_Nascita =< '" & dataFinale & " ');"
o cose simili...
dal lato applicativo (VB), le impostazioni che "valgono" al fine dell'interpretazione dei dati sono sempre legate alla locale dell'account in esecuzione...
quindi la data "teorica"
02/03/2020
potrebbe benissimo essere interpretata, a seconda dei casi, in 2 marzo oppure 3 febbraio, ed il risultato NON e' uguale :D
... come anche sollevare un'eccezione di parsing...
quindi, a ripilogo, per SQL Server, dove "dovuto", usare sempre il formato ISO yyyy-MM-dd...
nel caso, quindi, caricare
CMD.CommandText = "Select * from dbo.persone WHERE (Data_Nascita >= '2020-02-13' and Data_Nascita =< '2020-03-02')
ma, in ogni caso, utilizzare SEMPRE i parameters per caricare i parametri da utilizzare nelle queries...
salutoni
--
Andrea