Newsgroup: it.comp.appl.access
Titolo: Duplicare record.

Ciao a tutti di nuovo,
l'oggetto è abbastanza generico ma ora mi spiego meglio.
Ho una tabella così composta
IDRiga    Qtà
Tale tabella (ovviamente semplificata) la porto su una casella di riepilogo.
Ho un tasto che mi permette di inserire un valore Qta_provvisoria e a
seguito dell'inserimento devo fare la seguente operazione:
Verificare se la qtà corrisponde a qta_prov.
1)Se qtà è  = < a qtà_prov sono a posto
2)Se qtà è > qtà prov devo:
modificare qtà della riga selezionata in qtà_prov
duplicare il record selezionato tale e quale ma con qta = qta (precedente) -
qta_prov.
Il mio primo pensiero è quello di leggere tutti i campi del record
selezionato tramite dlookup e meomorizzarlo su variabili.
Se si verifica la condizione 2 eseguire un docmd.sql accodando un record
duplicato con modificata opportunamente la qtà e poi di seguito con un altro
docmd.sql aggiornare la qtà del record selezionato come descritto sopra.
Mi chiedo se esiste qualche sistema meno laborioso o più adeguato.
Grazie per l'aiuto
Ciao
Jef

 Mi chiedo se esiste qualche sistema meno laborioso o più adeguato.
    Direi che il flusso da te proposto sia adeguato.
    La realizzazione potrebbe essere invece un'altra: una volta verificato
che qtà > qtà_prov potresti eseguire due query con parametri, una di
aggiornamento ed una di accodamento (basata su una di selezione), senza
usare dlookup.
    Per esempio, ipotizzando la:
Tabella: x Jef
ID     Numerico lungo, Chiave primaria;
IDRiga Numerico intero;
qtà    Numerico intero.
le query potrebbero essere:
Query: x Jef Agg
PARAMETERS [ID?] Long, [qtà?] Short;
UPDATE [x Jef] SET [x Jef].qtà = [qtà?]
WHERE [x Jef].ID=[ID?];
Query: x Jef Sel
PARAMETERS [ID?] Long;
SELECT [x Jef].IDRiga
FROM [x Jef]
WHERE [x Jef].ID=[ID?];
Query: x Jef Acc
PARAMETERS [qtà?] Short;
INSERT INTO [x Jef] ( IDRiga, qtà )
SELECT [x Jef Sel].[IDRiga], [qtà?] AS qtà
FROM [x Jef Sel];
--
Ciao :-)
Maurizio
--------
?SPQR(C)
 X
--------

 ha scritto nel messaggio
news:b036vo$l4dgh$1...@ID-52090.news.dfncis.de...

Partendo dal presupposto che ho capito il tuo ragionamento e che lo
condivido ho due dubbi:
1) non conosco PARAMETERS nella struttura della query io di solito uso WHERE
ecc. ecc. (magari ti sto sparando una cazzata) Io normalmente creo la query
con crea nuova query e poi copio d ibrutto l'SQL nella finestra "visualizza
SQL" opportunamente modificato se devo inserire campi da codice.
2) Pensavo (e qui forse mi sbaglio) che fosse più opporuno usare recordset
ecc. ecc. da codice. (non sono capace 1° di tutto perché non ho mai trovato
un caso che mi obbligasse ad utilizzarli - vedi miei post precedenti - e 2°
forse era la scusa buna per studiare ed imparare DAO o ADO. Mi ripeto: non
ho ancora capito l'utilità rispetto a Docmd.runsql per operare su tabelle.
In ogni caso grazie 1000 per l'aiuto ed il tempo che ti (e vi , pensando
anche agli altri)  rubo
Ciao

 ho ancora capito l'utilità rispetto a Docmd.runsql per operare su tabelle.
[...]
    La questione di runsql come in generale l'uso dei metodi di docmd sono
strettamente legati allo stile generale del codice che scrivi. Tali metodi
(ottimi) sono fatti apposta per una scrittura veloce del codice ma impongono
alcune limitazioni. Trovare un equilibrio non e' cosa facile, soprattutto
agli inizi (ma non solo). Per dirla con una battuta: meglio si conoscono i
metodi di docmd meglio si programma, meglio si programma meno li si usa. :-)
    Considera anche che il codice che fa uso di docmd deve necessariamente
girare sotto access quindi se si prevede di migrare l'applicativo sotto
altri linguaggi o se si lavora contemporaneamente con altri ambienti di
programmazione (tipicamente visual basic) e' meglio scordarsi di docmd.


 ha scritto nel messaggio
news:b03ipt$kvkoc$1...@ID-52090.news.dfncis.de...

Grazie 1000 per risposta esuriente.