Newsgroup: it.comp.appl.access
Titolo: 'logica' nell'uso dei campi data...

Dunque fatemi capire cosa è un campo data per access perchè mi sfugge il suo
utilizzo.
Ho creato una tabella con dentro un campo data. Ne ho definito il formato
(data in cifre). L'esempio riporta una data come questa:
Data in cifre 19/06/1994
Lancio una query in cui il mio campo data deve essere uguale a 06/10/2003
Scrivo la query, questa:
SELECT CAMPI FROM TABELLA WHERE CAMPO_DATA = #06/10/2003#
Sebbene esiste un record che soddisfa questa condizione non vedo nulla. Dopo
un po di fanta access gli faccio creare la query a lui e scopro che la data
la mette in un formato 'suo'. Ovvero:
mese/giorno/anno
Bhà...non ho parole.
Saluti...
--------------------------------
Inviato via 
http://usenet.libero.it

 ha scritto nel messaggio
news:151Z24Z199Z210Y...@usenet.libero.it...

Esattamente.
Se la crei con QBE non c'è problema, l'interprete di Access la riconosce e
converte.
Se la crei da Codice, l'interprete sei tu e devi arrangiarti a correggerla.
Non c'è molto da dire purtroppo, mamma MS ne ha fatta un'altra....!
"SELECT CAMPI FROM TABELLA WHERE CAMPO_DATA =#" & Format(TuaData,
"mm\/dd\/yyyy") & "#;"
Ciao.
@Alex.

 un'altra....!
Ha farne ne fa tante, il problema č che non ne fanno mai una fatta come
cristo comanda! :)
Grazie, saluti...


 un'altra....!
Non sono molto d'accordo. Il codice access è slegato dalle impostazioni
internazionali del computer. In caso contrario ogni frammento di codice che
contenga funzioni data/ora andrebbe riscritto a seconda delle impostazioni
del computer. Per far valutare l'input all'italiana si dovrebbe usare
Format(), o qualcosa del genere.
-- 
Saluti 
gs - il vicino di homer è ned.flanders
Dio c'e', ma forse non vuol essere coinvolto.

 ha scritto nel messaggio
news:blpo2e$vce$1...@lacerta.tiscalinet.it...

Perdonami Alessandro, ma non sono d'accordo che questa volta mamma MS ne
abbia fatta un'altra delle sue; questa volta siamo noi italiani che quasi
sempre scriviamo le date non nel formato considerato standard per i
linguaggi di programmazione (VBA e SQL compresi), ovvero nella forma
anglosassone (mm/dd/yyyy alias mm/gg/aaaa).
Anzi mamma MS ha cercato di venirci incontro nel seguente modo:
1) Se si scrive usando direttamente i linguaggi VBA o SQL non ci sono
alternative, occorre assolutamente rispettare lo standard di quei linguaggi
e quindi, tra l'altro, occorre scrivere le date nella forma mm/dd/yyyy:
quindi la costante data "sei ottobre 2003" dovrà essere scritta #10/06/2003#
(e non #06/10/2003#  che viene intepretata come 10 giugno 2003) e se si fa
riferimento ad una variabile o campo di tipo Data/ora riempito
all'"italiana" occorre normalizzare il dato con una funzione Format ( ovvero
Format([MiaData], "mm/dd/yyyy") ). Se si usano direttamente quei linguaggi
di programmazione, oltre al formato delle date occorre ricordarsi che il
separatore decimale è il punto e non la virgola, il separatore di elenco è
la virgola e non il punto e virgola e nei formati si deve scrivere dd e non
gg, yyyy e non aaaa.
2) Se invece si fa ricorso al generatore di espressioni (e la griglia di
struttura di una query ne è un esempio), Access effettua lui la
normalizzazione verso gli standard dei linguaggi VBA ed SQL tenendo conto
delle Impostazioni internazionale di Windows del computer su cui si sta
lavorando.
Se ti dà noia questo dualismo è suficiente che come Impostazioni
internazionali di Windows scegli quelle inglesi invece che quelle italiane:
naturalmente con tutte le conseguenze del caso, compreso il fatto che devi
scrivre le date nella forma anglosassone
Le regole sono regole, anche per noi italiani. ;-)
-- 
Roberto
---------------------------------------------
il Sito Comune di it.comp.appl.access:
http://www.sitocomune.com
---------------------------------------------

 wrote in message
news:dQagb.13511$
e6.4...@twister2.libero.it
[CUT]

Ciao Roberto.
Forse mi sono espresso male sulla considerazione MS.
Ritengo aprezzabile che con QBE sia automatica la conversione,
e la mia riflessione era proprio dovuta alla differenza tra
QBE e SQL via codice.
Io avrei preferito non dover pensare che se faccio una QRY
con QBE la conversione è AUTO e viceversa se lo faccio via
codice devo inserire FOrmat(....).
Concordo con quello che dici, ma da non programmatore, anzi
smanettone quale sono, le accezioni sono forse + antipatiche che
altro.
Il vantaggio se MS avesse lasciato tutto come è lo standard anglosassone
sarebbe stato grande, in quanto è così anche per altri DB_Server.
Così invece valgono le eccezioni, un pò come la "," e il ";" nelle
funzioni scritte in VBA e direttamente con Generatore....!
Per il mio modo di impostare le cose non amo assolutamente il
fuori Standard.
Non sò se ho chiarito il mio punto di vista.
Saluti.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 

Ciao Roberto.
Forse mi sono espresso male sulla considerazione MS dando adito
a interpretazioni legittimamente in contraddizione.
Ritengo aprezzabile che con QBE sia automatica la conversione,
e la mia riflessione era proprio dovuta alla differenza tra
QBE e SQL(Standard) via codice.
Personalmente faccio quasi tutto con il codice, e non solo per Access
anche con MySQL o SQL_Server le cose sono =, per questo trovo
poco utile l'agevolazione di MS in QBE.
Concordo con quello che dici, ma da non programmatore, anzi
smanettone quale sono, le accezioni sono forse + antipatiche che
altro, perchè mi impongono molte volte di adeguare cose che dovrebbero
essere standard come il linguaggio SQL ad eccezioni quasi esclusivamente
MS.
Non si tratta di trovare fastidioso il dualismo, si tratta
di avere a disposizione un buono strumento, ma che personalemte,
e sottolineo, personalemte ritengo traviante.
Se anche seguissi il tuo consiglio, poi avrei problemi con la
distribuzione nel mio ambiente di lavoro.
In ogni caso tutto quello che è fuori dallo standard per il mio
modo di vedere le cose è utile solo per i non addetti ai lavori,
per gli altri, nel senso dei più smaliziati, non serve a nulla.
Dal mio punto di vista, anche se puramente personale, il fuori
standard è solo dannoso.
Vedi anche il ";" piuttosto che la "," nelle composizioni delle
funzioni da Generatore piuttosto che da codice..., vedi la chiamata
di Maschera invece che Forms... ci sono mille esempi di assurdità
fatte per agevolare il programmatore poco esperto....!!!!!


 Format(), o qualcosa del genere.
Esattamente così....!!
Ti sei abbondantemente sbagliato, solo forse non hai
mai fatto una QRY SQL via codice, quindi non hai mai
incontrato il problema.
Informati sulla cosa poi ne riparliamo.


 incontrato il problema.
dove avrei errato?
qui? -> Il codice access č slegato dalle impostazioni internazionali del
	computer.
qui? -> In caso contrario ogni frammento di codice che contenente funzioni
	data/ora andrebbe riscritto a seconda delle impostazioni del computer.
oppure qui? -> Per far valutare l'input all'italiana si dovrebbe usare
	Format(), o qualcosa del genere.
-- 
Saluti 
gs - il vicino di homer č ned.flanders

 ha scritto nel messaggio
news:f04a694ab98362089b...@mygate.mailgate.org...

E' sicuramente un problema di punti di vista. :)


 wrote in message
news:bls0kc$aoc$
1...@newsreader.mailgate.org

In entrambe 3.....!
Quello che dici č tutto legato, solo non ti sei accorto del problema.
Se componi via codice una QRY SQL in cui inserisci dei criteri WHERE
su campi data ti accorgi che no funziona, a meno di no Formattare
con la funzione FORMAT() che tu dicevi non servisse.
Il tutto se invece lo componi tramite il generatore di QRY(QBE)
č trasparente e viene Automaticamente convertito da Access.
Quello di cui io Roberto parlavamo era la filosofia di questa
gestione, reale ed esistente.
Ripeto se ti documenti sulla cosa possiamo insistere nell'approfondire.


 Ripeto se ti documenti sulla cosa possiamo insistere nell'approfondire.
Basta così, grazie.
-- 
Saluti 
gs - il vicino di homer è ned.flanders
Sapevate che i cloni non usano mai gli specchi?
		-- Ambrose Bierce, "The Devil's Dictionary"

 Basta cosě, grazie.
Concordo.
