Newsgroup: it.comp.software.database
Titolo: Scambiare due colonne

Salve a tutti,
utilizzo firebird e vorrei fare una cosa del genere:
UPDATE tabella SET campo1=campo2, campo2=campo1 WHERE ....
Ovviamente così mi setta entrambi i campi allo stesso valore.
C'è una maniera alternativa in SQL puro (senza usare stored procedure) per
fare questa cosa?
L'unica cosa che mi viene in mente è aggiungere una colonna a runtime o una
tabella di appoggio, e poi eliminarla ma non mi piace molto come soluzione.
Grazie
-- 
DBMS Firebird
VB6 + Ado

 UPDATE tabella SET campo1=campo2, campo2=campo1 WHERE ....
Non conosco firebird, ma alcuni DB permettono di rinominare le colonne
con alter table.
Bye.
-- 
Alessandro Pellizzari

 con alter table.
Si lo permetterebbe, ma il problema è che devo scambiare i campi che
soddisfano un filtro immesso dall'utente, quindi non posso fare l'Alter.
Ti ringrazio comunque	


"Andrea" <nos...@invalid.invalid> ha scritto nel messaggio
news:1aphitk0val5p$.1a9cl9nu8oxf2$.dlg@40tude.net...

Perchè no con una SP ??? passi la clausula Where, i campi da cambiare, e il
resto viene fatto lato server, ricarichi e hai il tutto già pronto :)
Saluti Goblin

 resto viene fatto lato server, ricarichi e hai il tutto già pronto :)
Hai perfettamente ragione, il problema è che l'archivio non ne ha nessuna
per adesso, e farla per questo mi sembrava uno spreco.
Inoltre dato che un'altro tipo di calcolo doveva fare una cosa *per forza*
lato client, anche questa lo fatta in vb6 scorrendo i record che rispettano
il filtro e facendo tante UPDATE.
Naturalmente è meno prestazionale, ma come velocità per ora mi va bene.
Una volta terminato il programma a cui sto lavorando avevo in mente di
sostituire alcune routine con SP per ottimizzarne la velocità, ma volevo
fare tutto in un secondo momento, ora non ne ho il tempo.
Tnx

 fare questa cosa?
Questo risultato non è affatto "ovvio": non conosco firebird ma se la
query che scrivi setta entrambi i campi allo stesso valore significa
che firebird non rispetta il principio dell'atomicità delle istruzioni
SQL.
L'istruzione SQL è una dichiarazione, non dice che prima deve settare
campo1=campo2 e poi campo2=campo1 ma è come se tutta l'operazione
avvenisse in un unico istante del tempo (anche se l'implementazione
ovviamente effettuerà le modifiche in istanti successivi questo non
dovrebbe influire sul risultato della query).
Ad esempio con Oracle funziona:
SQL> create table prova (campo1 number, campo2 number);
Table created.
SQL> insert into prova values(1,2);
1 row created.
SQL> select * from prova;
    CAMPO1     CAMPO2
---------- ----------
         1          2
SQL> update prova set campo1=campo2, campo2=campo1;
1 row updated.
SQL> select * from prova;
    CAMPO1     CAMPO2
---------- ----------
         2          1
Ciao.

 dovrebbe influire sul risultato della query).
Infatti anche io pensavo e speravo avvenisse in quel modo.
L'unica sarebbe usare una stored procedure, ma per ora per velocità (non di
esecuzione ma per fare la procedura) e uniformità di funzionamento ho fatto
io da codice.
Tnx

 l'operazione avvenisse in un unico istante del tempo
L'atomicità è una proprietà delle transazioni che specifica che
un gruppo di istruzioni è una unità indivisibile (atomico = senza
parti), con la conseguenza che le istruzioni così raggruppate hanno
effetto o tutte o nessuna (essendo multi-riga, anche per un singolo
comando sql viene avviata una transazione invisibile).
Il fenomeno in questione invece mi sembra una conseguenza del
fatto che l'SQL, essendo come hai detto, linguaggio dichiarativo,
impone che il risultato sia indipendente dall'ordine di valutazione
(e questo è desiderabile: nessun effetto collaterale, né "casi
particolari" come quello sopra da ricordarsi etc).

The man with two watches ha scritto:

Grazie della precisazione: mi sono chiarito un termine che utilizzavo a
sproposito. C'è sempre qualcosa da imparare.