Newsgroup: it.comp.programmare.win32
Titolo: ListBox->STream

Strings[i]...................SavetoStream
            }
         __finally {
              delete TempList; // distrugge l'oggetto lista
                   }
grazie a tutti

 faccio a passare le 3 righe alla lista?
    for (int i = 0; i < ListBox2->Items->Count; i += 3)
    {
        try
        {
            AnsiString SQL = ListBox2->Items->Strings[i];
            SQL += ListBox2->Items->Strings[i + 1];
            SQL += ListBox2->Items->Strings[i + 2];
            // esegui SQL
        }
        catch (...) { }
    }
HTH,
-- 
Stefano Frosio
www.esse-effe.com

On 25 Lug, 13:32, "Stefano Frosio"

grazie mille del consiglio
ma ora una volta eseguita la mia Query dovrei
eseguire la successiva sulle prossime 3 righe dovrei fare una altro
ciclo a monte
queste sarebbero le mie query
UPDATE TABELLA SET
    CAMPO1 = 55
WHERE (CAMPO_KEY = '0271221    ');
UPDATE TABELLA SET
    CAMPO1 = 58
WHERE (CAMPO_KEY = '0273080    ');
UPDATE TABELLA SET
    CAMPO1 = 1111
WHERE (CAMPO_KEY = '0357280    ');
UPDATE TABELLA SET
   CAMPO1 = 1111
WHERE (CAMPO_KEY = '0368010    ');
UPDATE TABELLA SET
    CAMPO1 = 123
WHERE (CAMPO_KEY = '9389894    ');
in questo modo eseguo la prima query di 3 righe (0-1-2)
come faccio a mettergli l'altro ciclo a monte di questo che poi mi
passi alla riga 3-4-5
grazie ancora


pardon ho sbagliato funziona
almeno per verificare ora l'output  lo mando in un'altra ListBox
e' l'unico modo?
grazie

 e' l'unico modo?
Ma no, ce ne sono quanti ne vuoi (in primis il debug). Per 
esempio puoi visualizzare ogni query in un message box:
    ShowMessage(SQL);
-- 
Stefano Frosio
www.esse-effe.com

             // esegui SQL
Per favore non farlo :)
Quel modo di procedere è vulnerabile alla sql injection.
È sempre bene usare i parameters di un command per diversi motivi:
- performance
- evitare i problemi dei separatori di date e numeri
- pararsi dalla sql injection.
BTW se a qualcuno interessa ho scritto un articolo sull'argomento:
http://msdn.microsoft.com/it-it/library/cc185099.aspx
-- 
Raffaele Rialdi
Microsoft .NET MVP 
http://mvp.support.microsoft.com
 -
http://italy.mvps.org
 UGIdotNET - User Group Italiano .NET
http://www.ugidotnet.org
 Weblog: 
http://blogs.ugidotnet.org/raffaele

 un articolo sull'argomento:
Ah, capito.
-- 
Stefano Frosio
www.esse-effe.com

 Sì, ma se lui dal file deve prelevare tutta la query...
Anche sulle query che costruisci dinamicamente e al volo puoi usare i 
parametri... costruisci la stringa concatenando "@param1" e poi 
aggiungi il corrispondente parametro alla collection dei parameters.
Se poi riutilizzi quella query cambiando solo il valore del parametro 
ottieni anche migliori perf.


 Megli usare i command + parametri e via.
E sono d'accordo, ma se il file arriva già così da chissà quale 
applicazione non ci si può fare molto.
-- 
Stefano Frosio
www.esse-effe.com

 non ci si può fare molto.
Questa non l'ho capita. Visto che la stringa ce l'hai tra le mani e i 
parametri vengono aggiunti concatenandoli, l'uso dei parametri non è un 
problema.


 tutto il resto fornisce solo benefici e non costa nulla.
Hai visto l'esempio di file che ha postato l'OP? Puoi spiegare 
cortesemente come utilizzare i parametri in quel caso? E' solo 
una domanda eh, puň benissimo darsi che sia io a non vedere una 
soluzione ovvia.
Comunque la critica era piů rivolta al discorso "SQL injection" 
che al resto.
-- 
Stefano Frosio
www.esse-effe.com

resto fornisce solo benefici e non costa nulla.
E dalle :-)
Che usare i parametri sia di gran lunga la cosa migliore da fare,
credo che Stefano - come la maggior parte dei programmatori esperti -
lo sappia bene. Ma in quel codice non sta componendo uno statement SQL
a mano, sta prelevando lo statement da file...

 Comunque la critica era più rivolta al discorso "SQL injection" che al resto.
Ho capito ... ti dico che ho visto una sql injection per valori che 
venivano prelevati dal db locale. Il developer credeva di potersi 
fidare di ciò che era sul db e invece in quei campi erano finite delle 
stringhe provenienti da un'altra applicazione che scriveva su db i 
valori senza alcuna validazione.
Che sia poco probabile concordo, che valga la pena di usare i 
parameters sempre credo che tu sia daccordo.


 a mano, sta prelevando lo statement da file...
Io mi sono solo limitato a sollevare il problema che molto 
probabilmente Stefano conosce alla perfezione, ma statisticamente non 
tutti quelli che lurkano i ng. Meglio un bell'avviso, no?
Per il resto dipende molto da cosa c'è in quel file. Se la query è 
sempre quella che è stata postata, prelevare i valori e metterli nei 
parameter è semplice.


tutti quelli che lurkano i ng. Meglio un bell'avviso, no?
Il fatto è che non si stava parlando di quel problema e questo tuo
insistere su un punto che *non è* il punto della questione è piuttosto
fuorviante. Se stiamo parlando della coltivazione delle mele non c'è
poi alcun male nel sollevare i problemi legati alla coltivazione delle
patate, è solo che le due questioni non sono molto attinenti. Diciamo
che hai colto un'occasione per fare pubblicità al tuo articolo ;-)

 che hai colto un'occasione per fare pubblicità al tuo articolo ;-)
Libero di pensarla così ma non era assolutamente il mio intento


 parameters sempre credo che tu sia daccordo.
Sul "sempre" no, non sono d'accordo. Per ogni problema si 
trovano determinate soluzioni.
-- 
Stefano Frosio
www.esse-effe.com