Newsgroup: it.comp.lang.visual-basic
Titolo: date e sql server

come devo inserire una data in una query INSERT in SQL Server?
set rst = cnn.execute ("INSERT INTO Tabella (ID, Data) VALUES (100,
#2/12/2002#)"
mi da un errore.
qual è il formato giusto per le date? in Access funzionava benissimo...
grazie.
Mario

Prova con convert:
convert(datetime,'"+tuadata+"',103)

 qual è il formato giusto per le date? in Access funzionava benissimo...
In SQL Server puoi utilizzare il formato ISO (yyyymmdd) che ti permette di
gestire le date indipendentemente dalle Regional Options.
Ipotizzando che la data da inserire sia il 12 febbraio 2002 scriverai:
set rst = cnn.execute ("INSERT INTO Tabella (ID, Data) VALUES (100,
'20020212')"
Come suggerito da Cristiano, in fase di lettura sarai libero di formattare
la data come vuoi, ricorrendo alla funzione T-SQL CONVERT.
Ciao!
--
Lorenzo Benaglia
UGIdotNET - 
http://www.ugidotnet.org

 ha scritto nel messaggio
news:aen6vc$8bb5e$1...@ID-70152.news.dfncis.de...

La volete capire di non usare mai i campi Date?!

La volete capire di non usare mai i campi Date?!
E tu come fai di solito?
Aran

 E tu come fai di solito?
Testo nella forma "AAAAMMGG" e amerai la vita (non la M$, perň...)

Testo nella forma "AAAAMMGG" e amerai la vita (non la M$, però...)
E per il data-entry?
Controlli tutti i campi data o semplicemente dici al cliente di
inserirli "AAAAMMGG" ?
Ciao
Aran

> La volete capire di non usare mai i campi Date?!
Stai scherzando, vero?


 inserirli "AAAAMMGG" ?
Un software fatto bene non collega mai un campo del DB con un textbox o un
altro controllo, e passa sempre e comunque attraverso un controllo di
validità.
Per cui, non costa niente formattare il testo come YYYYMMDD.
Alberto

Per cui, non costa niente formattare il testo come YYYYMMDD.
Io collego i campi direttamente al DB, ed effettuo il Validate nei
campi "critici" (passami il termine).
Ma se per ogni campo data devo stare lì a fare conti e conti....
E poi, quando devo fare calcoli con date (e ti assicuro che ne faccio)
devo stare lì a riconvertire?
Ciao
Aran

 devi fare dei calcoli sulle scadenze, ecc...
Esatto, a parte i problemi di performances e di bytes sprecati che derivano
dalla gestione delle stringhe (il datetime è gestito internamente da SQL
Server come  4-byte integers), i veri problemi derivano dalla manipolazione
delle stringhe nel caso in cui sia necessario effettuare dei calcoli. SQL
Server mette a disposizione una miriade di funzioni per la gestione delle
date.
Il consiglio che vi posso dare è il seguente:
- Create stored procedures che accettino paremetri di input di tipo
datetime;
- Lato Client utilizzare variabili di tipo Date per memorizzare le date ed
utilizzatele come parametri di input tramite oggetti ADO Command.
Se proprio non volete ricorrere alle SPs (grosso errore....), utilizzate il
formato ISO (YYYYMMDD) per formattare le date prima di utilizzarle nelle
query ad-hoc.
Per maggiori informazioni leggete questo articolo:
http://www.sqlmag.com/Articles/Index.cfm?ArticleID=9147
Ciao!


date.
E se non uso SQL Server ma un altro DB (es. Access, MySQL etc. etc.?)
Ciao
Aran

 ha scritto

be', con access anche vb con le date ti lascia fare parecchio...


wrote:

Appunto, quindi non capisco perché non dovrei usare i campi date.
Dipende tutto dal contesto.....
Ciao,
Aran

 devo stare lì a riconvertire?
????
Veramente io ho detto che conviene usare i campi data se devi fare dei
calcoli, per cui non capisco la tua domanda.
Alberto

"Lorenzo Benaglia" <lben...@NOSPAMtin.it> ha scritto nel messaggio
news:aengv8$cen$1...@fe2.cs.interbusiness.it...
[cut]
Direi che siamo sintonizzati al 100%
Alberto

 E se non uso SQL Server ma un altro DB (es. Access, MySQL etc. etc.?)
L'unico DB sfigato nella gestione delle date è Access. Per tutti gli altri
esiste sempre il modo di scrivere le stringhe SQL in maniera compatibile.
E comunque il thread parla di Sql-Server.
Alberto

> E se non uso SQL Server ma un altro DB (es. Access, MySQL etc. etc.?)
Premesso che il thread si riferiva alla gestione delle date in SQL Server,
ricordo che in Access sono disponibili altre funzioni per gestire le date.
Per quanto riguarda MySQL non saprei dato che non l'ho mai utilizzato.
Ad ogni modo se esistono dei datatype nativi, perché non utilizzarli?


E comunque il thread parla di Sql-Server.
Faccio ammenda....
mi ero lasciato prendere dal discorso....
in effetti si paralva di SQL Server.
chiedo scusa
Aran

 Dipende tutto dal contesto.....
infatti anch'io, nonostante sia cresciuto a cobol clipper e ansidate, me li
tengo stretti. la sola idea di farmi una datediff mi angoscia alquanto. e il
check su un text dev'essere ferreo.
nb pero' che le date valgono quel che valgono. in clipper mi ero dovuto fare
acoorto che weekday e simili per date vecchiotte (settecento e prima),
calendari perpetui alla mano, erano discretamente sballate...
ciao, a.

 Stai scherzando, vero?
No! Li ho eliminati ovunque!

 inserirli "AAAAMMGG" ?
Verifico l'input di ogni cosa con le mie routines di controllo su ogni
singolo tasto premuto (sě, anche gg del mese e bisestili), le date in
particolare nella forma GGMMAAs (con s che sta per secolo, > per seguente, =
per corrente, < per precedente) e poi le converto come mi pare e piace.



Vedo piů semplice usare i campi DATE se sono supportati dal DB....
Cmq a ognuno le proprie idee.
ciao
Aran

 Cmq a ognuno le proprie idee.
Secondo me state discutendo di due cose diverse:
Lupo parla di controlli da fare in VB, prima di eseguire l'Insert o
l'Update;
Aran parla della sintassi per l'Insert o l'Update, e del tipo di campi da
usare nel DB.
Credo che in fondo abbiate ragione entrambi:
Occorre controllare i valori inseriti dall'utente, per verificare che siano
valori accettabili (pensate semplicemente a cosa succede se l'operatore
inserisce un apicino in una textbox), e successivamente è corretto
utilizzare campi Date nel DB, ed inserirli con la giusta sintassi.
L'affermazione di Lupo "La volete capire di non usare mai i campi Date?!" è
troppo drastica.
SQL (a parte Access) accetta Insert, Update, Where, ecc..., usando la
stringa 'YYYYMMDD' come valore di tipo Date, per cui è del tutto
indifferente che il campo sia memorizzato come stringa o date (a parte
giustamente lo spazio occupato, che con i char sarebbe maggiore).
Tuttavia eseguire una cosa semplice, del tipo "estrai i record con data di
scadenza a meno di x giorni dalla scadenza di quell'altro record", diventa
una cosa molto complessa se il campo è di tipo testo, mentre è semplicissimo
usando DateDiff.
Si potrebbe dire che, se serve una data, basta mettere il "Cast as Date", ma
a questo punto scendiamo su efficienze delle query che credo diventino
improponibili con join complessi.
Ciao
Alberto

troppo drastica.
[CUT]
Purtoppo la mia esperienza con SQL Server non è molta....
Solitamente per le mie applicazioni basta Access.
Nelle Select, se servono date, inserisco il classico FORMAT e tutto
funziona. C'è da dire comunque che non opero su un numero elevatissimo
di record....
Ciao
Aran