Newsgroup: it.comp.lang.visual-basic
Titolo: ?Due query in una

Uso DAO 3.6
Modifico la precedente predefinita
    SQLQuery = "UPDATE LuogoLavoro SET LuogoLavoro.Predefinita = False" _
        & " WHERE LuogoLavoro.Predefinita=True"
    CurrentDB.Execute SQLQuery, dbFailOnError
Imposto la nuova predefinita
    SQLQuery = "UPDATE LuogoLavoro SET LuogoLavoro.Predefinita = True" _
        & " WHERE LuogoLavoro.IDLuogo=" & lngIDLuogo
    CurrentDB.Execute SQLQuery, dbFailOnError
Volevo sapere se fosse possibile fare entrambe le cose con una sola query.
Grazie
Carmelo 

Sembra che Carmelo abbia detto :

Hai provato?
Con Sql-Server non ci sarebbe alcun problema, basta lasciare uno spazio 
fra le due stringhe concatenate. Forse con Access ci vuole il ';' o 
qualcosa del genere, ma dovrebbe funzionare.
Nel caso specifico, puoi anche utilizzare un IIF un po' elaborato nel 
SET.
Se la tua necessità è però per un discorso di integrità, meglio che tu 
valuti l'utilizzo di Transazioni (anche se in Access la transazione è 
una mezza presa per il culo).
Aggiungiamo che se lngIDLuogo è un Long, sarebbe bene aggiungere un 
CStr davanti.
Ciao
Alberto
-- 
A questo punto hanno trovato un muro,
un muro duro, molto molto duro,
che siamo noi.

 ha scritto nel messaggio 
news:mn.7b587d65f...@hotmail.com...

Perchè CStr visto che LuogoLavoro.IDLuogo è long?
Carmelo 

 Perchè CStr visto che LuogoLavoro.IDLuogo è long?
Perche SQLQuery contiene una stringa unita a un long 
(".......................Idluogo=" &  lngIDLuogo) al 99% dei casi non 
importa... ma a volte, ci sono comportamenti anomali, che non recuperi piu 
perche il codice è tutto ok... metti il Cstr e tutto va a posto come 
dovrebbe....
Penso che quello di Albe fosse solo un appunto di 1) stile, 2) prevenzione, 
che condivido appieno ^.^ 

 prevenzione, che condivido appieno ^.^
Io non in questo caso.
Le conversioni numeriche implicite vengono fatte da VB secondo le 
impostazioni internazionali (più o meno) allo stesso modo del CStr, che in 
questi casi risulta inutile.
Ciao

Fabio ha usato la sua tastiera per scrivere :

Le conversioni implicite sono comunque un male.
Non tanto perchè non funzionino (perchè, in questo caso, ad esempio, il 
CStr equivale a non mettere niente), ma perchè rendono meno leggibile 
il codice.
Se non metti il CStr, leggendo il codice sembra che avvenga una 
semplice concatenazione di stringhe. E per capire che non è così, 
occorre leggere per bene il nome di ogni singola variabile, e sperare 
che sia stata codificata correttamente. Immagina, ad esempio, che 
domani la variabile diventi Currency, perchè serve per altre cose, ma 
che per 'fretta' non si faccia il Sostituisci in tutto il progetto 
(perchè il sostituisci va fatto con "successivo", e non con 
'Sostituisci tutto', perchè lo stesso nome di variabile locale può 
essere usato in mille occorrenze, quindi richiede del tempo).
Trascurando il fatto che ci si ritrovi con lngPippo che è in realtà un 
Currency, si ha comunque l'anomalia di avere una concatenazione 'a 
rischio', visto che i Currency usano il separatore decimale locale, se 
convertiti implicitamente. Al che c'è il bug, al che si capisce che è 
una conversione implicita, al che bisogna leggersi tutto il codice, 
anzichè cercare un CStr.
Dovendo essere precisi, sarebbe meglio usare Str, anzichè CStr, ma mi è 
scappata l'imprecisione.
Se la concatenazione avviene con Str, ciò che si legge è ciò che 
avviene, ossia PRIMA una conversione di tipo, POI una concatenazione.


 è scappata l'imprecisione.
A voler essere pignolissimi: bisognerebbe scrivere Trim(Str(...)), visto che Str
aggiunge un pressoché inutile spazio a sinistra...
Bye
Raf

> Carmelo
AFAIK Access/Jet non supporta i batch multipli, bisogna eseguirle una alla
volta.
Bye
Raf

 ossia PRIMA una conversione di tipo, POI una concatenazione.
Questo non mi è chiaro.
Se non ricordo male Str differisce da CStr solo per il fatto che non è 
localizza, cioè Str sta a Val come CStr sta a CDbl e CLng.
Ciao 

 volta.
Anche  a me pare di ricordare una cosa del genere.
Però non vedo la necessità di eseguirle per forza insieme, probabilmente 
come dice Albe ti conviene metterle in una transazione.
Ciao 

 Questo non mi è chiaro.
Nel senso che
Stringa = "Valore = " & STR(LngPippo)
esegue DUE operazioni: una conversione (STR) e una concatenazione (&), 
ovviamente in quest'ordine.
Guarda, l'esempio più lampante del fatto che sia scorretto non 
esplicitare una conversione, è la quantità di post in cui si segnalano 
bug per conversioni implicite di cui la gente è del tutto ignara. Se 
tutti ci abituassimo a esplicitare le conversioni, chiunque, vedendo un 
codice d'esempio, noterebbe quella STR buttata lì, e si porrebbe il 
problema del 'perchè?', e nel giro di poco avrebbe capito. Postando 
invece del codice privo delle conversioni esplicitate, uno ritiene che 
non ci sia alcuna conversione, e la volta che usa un double poi si 
chiede come mai dia errore la stringa SQL che prima funzionava 
benissimo.


Il 15/05/2006, Fabio ha detto :

Aggiungo che la transazione andrebbe utilizzata anche se il batch fosse 
unico, perchè comunque verrebbe eseguito dal motore come due operazioni 
distinte, con la possibilità che fallisca la seconda ma non la prima.
Vero è, però, che con Access le transazioni sono una mezza cavolata, 
nel senso che se 'manca la scossa' a metà, il db resta comunque scritto 
per metà.


 conversioni implicite di cui la gente è del tutto ignara.
Questo perchè usano VB come se fosse una calcolatrice senza aver letto una 
sola pagina della guida.
Ho capito che faciliterebbe il compito di chi risponde (che poi non ne sono 
così sicuro, quante volte capita di leggere CStr(Eta) e poi scopri che Eta 
non è un numero ma una textbox con scritto dentro un numero), ma questo non 
sposta il problema.
Credo che la cosa migliore sia conoscere gli strumenti che si usano, ad es. 
io mi trovo benissimo con c# (anche con VB.net, ma non è altrettanto 
rigoroso) che vuole tutti i tipi, ma se il tuo programma è strutturato 
decentemente i pezzi si incastrano perfettamente senza far lamentare il 
compilatore.
Ciao 

 compilatore.
Il compilatore non si lamenta.
E' un discorso di leggibilità.
E, quindi, di produttività.


 l'esplicitazione di quel CStr(Eta).
Ehm, no.
In quel caso non ci sarebbe alcuna conversione implicita, ma solo 
l'apposizione della proprietà predefinita, perchè non si passerebbe mai 
per un numerico.
Mi confondevo con
Format$(Eta,"0.0")
che equivale a
Format$(CDbl(Eta.Text),"0.0")


Per quel che può servire JET fino alla versione 2003 non supporta
azioni multiple.
Concordo sulla scarsa efficienza delle transazioni, ma quello che offre
è quello
che si deve ottimizzare.
Con la nuova versione del Motore JET, ci saranno delle novità che lo
renderanno
decisamente più flessibile e sicuro.
Saluti
@Alex