Newsgroup: it.comp.lang.visual-basic
Titolo: Re: Errore con "set dateformat dmy"

 di errore.
Non ho mai provato ad impostare una cosa del genere all'interno di una 
Source, ma nel caso inserirei un GO fra il Set e il Select.
Ciao
Alberto
-- 
E tutto mi sembrava andasse bene... 

 sintassi.
Certo che funziona anche in Oracle.
Funziona in tutti i dbms degni di tale nome.
Infatti non funziona in Access :-))



Ho provato a mettere il go fra il set e la select ed il risultato č che non
riesce nemmeno ad aprire il recordset che altrimenti mi aprirebbe.
Sono ben disposto ad accettare qualsiasi suggerimento possa arrivare nel
frattempo grazie mille.
Ciao
Ale

 potessi essere piů chiaro (magari con un esempio)te en sarei grato
Select * from tabella
where data_ora>'20050221 11:25:36'
Il formato sopra ('yyyymmdd hh:mm:ss') funziona sempre e comunque, qualunque 
sia l'impostazione del server, del database e dell'utente.
Comunque sui BOL c'č parecchia roba su come scrivere applicazioni robuste 
rispetto alle impostazioni internazionali.
Ciao
Alberto

Salve a tutti, mi è sorto un problema che reputo bizzarro ed a cui non so
come porre rimedio...in pratica
VB6, SQLServer 2000, ADO 2.6
Apro un rs con una Select...from...where,
rs.movelast
tutto ok
Se in testa alla query Inserisco il "set dateformat dmy" per non avere
problemi con la formattazione della data nel momento in cui faccio
rs.movelast mi da l'errore
-
2147217884
 - The rowset does not support fetching backwards.
Per la cronaca, anche se non credo proprio che l'errore sia dovuto a questo,
il rs lo apro adopenstatic,adlockreadonly.
Grazie a tutti per l'aiuto


Tutto strano.
Innanzitutto il Set Dateformat ha un senso solo ed esclusivamente se fai un 
Cast o un Convert dei campi di tipo data, perchè se li estrai come campi 
DateTime o SmallDateTime, cioè mettendo semplicemente il nome del campo 
nell'elenco della select, il .Value del Field è una data e in quanto tale il 
formato non esiste proprio come concetto.
Secondo, l'errore che ti ritorna sembra legato proprio al tipo di cursore. 
Se non ti serve necessariamente lato server, spostalo lato client con 
CursorSide=AdUseClient.
Se non cambia niente, penserei ad un bug di Ado2.6, per cui potresti provare 
ad aggiornare a Ado2.8.
Altro caso in cui può verificarsi il problema, è se hai controlli bound ai 
dati, ma non ne fai menzione...



Avendo alcuni clienti che hanno SQL in italiano ed alcuni che ce l'hanno in
Inglese e non volendo traformare la data in numero (che tra l'altro
sarebbe -2) il set dateformat mi serve per la clausola where un cui faccio
il cast della data.
Ho provato a spostare il cursore come mi hai detto ma non cambia nulla.
Inoltre ho verificato ed anche in qs. caso senza il dateformat funziona
correttamente mentre se lo aggiungo ritorna lo stesso codice di errore.
Ho provato ad utilizzare ado2.8 ma mi ripete il comportamento anomalo se è
presente il set Dateformat.
Se hai altre idee sono comunque ben accette. Nel caso invece trovassi la
soluzione la posto in modo da poter essere utile ad altri.
Ciao
Ale

 Comunque sui BOL c'è parecchia roba su come scrivere applicazioni robuste


 Inviato via 
http://arianna.libero.it/usenet/
In oracle avevo appunto usato la "to_date" pensando poi di usare "set
dateformat" con la cast in sql cosa però che non ho potuto fare per l'errore
che descrivevo nella mail in apertura del thread...Dovendo quindi fare
invece uso della data con il formato yyyymmdd hh:mm:ss in SQLServer per
uniformità pensavo di utilizzare la stessa sintassi anche in Oracle. A
livello di pulizia del codice mi sembrerebbe la cosa migliore....o no!!! Poi
se mi dite che comunque in Oracle mi conviene utilizzare la to_date ci credo
e se non mi insultano lo faccio anche, ma a me sembra che  usando i
formalismi tutti uguali è mejo
Comunque se qualcuno mi sa risolvere il problema all'inizio riuscendo a
farmi usare il set dateformat come era mio desiderio(devo mettere meno mano
al codice) mi riempie di gioia.
Ciao ;-)
Ale

 al codice) mi riempie di gioia.
Mi spiace, non l'ho mai usato perche' IMHO e' solo fonte di casino, come
purtroppo stai sperimentando sulla tua pelle.
Questa funzione modifica il default del formato data in input per l'intera
connessione, quindi se, con la stessa connessione, non se ne tiene
conto, si tappa un buco per chiuderne un altro.
Se puoi, dai retta ad Alberto...


 In SQL funziona lo stesso, in oracle non so.
In oracle c'e' la comodissima funzione to_date che permette di
specificare come vada interpretata la stringa che viene passata,
tagliando cosi' la testa al toro.
Ad esempio:
select num_mov from movimenti
where data_mov >= to_date('01/01/2005', 'dd/mm/yyyy');
--


 where data_mov >= to_date('01/01/2005', 'dd/mm/yyyy');
Beh, anche in Sql-Server c'è la Convert, che consente di specificare la data 
in una moltitudine di formati, e di averla correttamente interpretata come 
valore DateTime.
Ma ritengo molto più pratico usare l'Iso, anche perchè se vuoi passare la 
data come l'hai scritta tu, sei obbligato ad utilizzare un Format$, e quindi 
dopo *devi* testare che il separatore di data sia la barra, e se non lo è 
devi sostituire il separatore locale con la barra, quindi non è che si tagli 
la testa al toro.
A onor del vero, neppure l'Iso è immune dalle impostazioni locali, 
quantomeno sul lato client, perchè i ':' (duepunti) che separano le ore, nel 
Format$ sono localizzati, quindi comunque occorre avere una propria funzione 
che testi l'esito del format$. Ma almeno con l'Iso, se non ti serve l'ora, 
sei già a posto col format$.


 Infatti non funziona in Access :-))
In access devi usare l'"ISO extended" :)
yyyy/mm/dd hh:mm:ss
In SQL funziona lo stesso, in oracle non so.
Ciao