Re: Problema con Thunderbird (Ver. 45.8.0)

[Portobello]

On 29/04/2017 19:14, Giancarlo Martini wrote:

forse è un problema di permessi sul file, la dir dove thunderbird
mette i messaggi dovrebbe essere .thunderbird, dai il comando
chown tuo_nome_account:tuo_nome_gruppo .thunderbir -R

Non so quale è il nome del mio gruppo. Non lo ho mai utilizzato.


dalla tua directory home, cosi facendo se c'è qualcosa che non va te ne accorgi


Da root ho dato questo comando :

# chown -R nomeutente .thunderbird

non ha restituito nessun errore al prompt del terminale, ma se poi vado 
sul client di posta di thunderbird non è cambiato nulla, i messaggi su 
due account non si possono cancellare.
Questo problema si è presentato soltanto da quando hanno fatto 
l'aggiornamento da Icedove a Thunderbird.

Ciao
Grazie




Il 29 aprile 2017 18:05, Portobello  ha scritto:

Buon Giorno Lista,

Utilizzo thunderbird con Debian Stable Jessie.
Da qualche giorno c'è stato un aggiornamento che ha tolto Ice... (ora mi
sfugge il nome ) ed ha rimesso thunderbird come client di posta.

Il problema, che ho notato, è che su due degli account di posta che ho, non
riesco più a cancellare i messaggi. Posso soltanto segnarli come spam e
posta indesiderata.

Ho guardato le impostazioni di tutti gli account di posta che ho e non vedo
differenze tra loro. Sugli altri account invece riesco ancora a cancellare i
messaggi come prima.

Grazie
Ciao

Re: SQL: incrementare valore

[Leonardo Boselli]

Informazione aggiuntiva: si lavora sempre su una sola riga, anche perché 
r_to è sempre >= r_fr, quindi dopo ogni aggiornamento max(r_co) di 
solito cambia. (dico di solito perché in casi molto particolari r_fr e 
r_to potrebbero essere uguali). se per caso dovessi aggiornare più di una 
riga la subselect dovrebbe comunque essere fatta ogni volta.

Il database è maria .

On Sat, 29 Apr 2017, Gian Uberto Lauri wrote:


On 29/04/2017 10:17, Federico Di Gregorio wrote:

Puoi fare:

UPDATE mee SET r_co = (SELECT max(r_co) FROM mee) + r_to - r_fr WHERE r_id 
= ...


Questa soluzione è sicuramente corretta solo se l'update va fatta su una 
singola riga.


Se invece si devono aggiornare in blocco N righe (i.e. 'where id in ...), 
allora AFAIK il risultato
dipende da come è stato implementato l'ottimizzatore di query: se decide di 
calcolare la max
una volta per tutte all'inizio si avrà un risultato, altrimenti se ne avrà un 
altro e tempi di

esecuzione più lunghi.

[E può anche esserci uno standard che sancisce uno o l'altro comportamento, 
bisogna

comunque vedere se il DBMS lo rispetta.]

In ogni caso, in dipendenza dalle esigenze della logica di business, si 
possono avere
due situazioni a seconda o meno che serva che venga ricalcolato il max per 
ogni riga, e
comunque affidarsi alla buona grazia dell'implementazione dell'ottimizzatore 
non è una
soluzione accettabile oggi. Lavorare come Mel andava bene negli anni '50/60 
del secolo

scorso.

La stored procedure rimane una soluzione affidabile ed elegante.
--
Gian, stavolta non su uno smartphone.





--
Leonardo Boselli
Dipartimento Ingegneria Civile e Ambientale UNIFI
tel +39 0552758808  +39 3488605348

Re: SQL: incrementare valore

[Paolo Redaelli]

Il 29/04/2017 22:49, Alessandro Pellizzari ha scritto:
> On 29/04/17 14:10, Giuliano Curti wrote:
>
>>> UPDATE mee SET r_co = (SELECT max(r_co) FROM mee) + r_to - r_fr WHERE
>>> r_id =
>> la funzione UPDATE itera su tutti i record, la funzione SELECT
>> nidificata, che anch'essa itera su tutti i record, non risulta
>> penalizzante? si avrebbe un algoritmo di complessità N**2;
> Questo vale solo se non hai indici sul DB.
Perdonatemi se mi intrometto, ma una bella EXPLAIN non risolverebbe
tutti i nostri dubbi?