2010-07-07 12 views

risposta

5

Ciò può verificarsi se si visualizzano le stesse righe in più di una DataWindow (non condivisa) e quindi si tenta di aggiornarle entrambe. Altre cause sono l'uso non corretto di SetItemStatus(); uso scorretto dei flag di stato nell'istruzione update(); e infine, la causa che si intende rilevare, un altro utente ha aggiornato la riga prima di te.

+1

Vedere anche [L'annotazione di Terry sulle irregolarità del database] (http://www.techno-kitten.com/PowerBuilder_Help/Troubleshooting/Database_Irregularities/database_irregularities.html). –

1

È stato risolto? Ci sono diversi motivi per cui questo potrebbe accadere, uno è se la riga è stata aggiornata da un altro utente. Nelle proprietà di aggiornamento del tuo oggetto dati puoi scegliere il metodo di aggiornamento, utilizzando il valore chiave, i valori chiave e modificato, o la chiave e tutte le colonne aggiornabili.

Se si è certi che non vi siano problemi di concorrenza, è possibile modificare questa impostazione in "usa solo valori chiave". Renderà la clausola where per gli aggiornamenti costituiti solo dal valore della chiave e le altre colonne non saranno valutate per le modifiche.

Può accadere se si verificano errori di convalida, è necessario ricordare di impostare lo stato dell'elemento su non modificato. Per impostare tutte le righe su non modificate, farei dw_1.setitemstatus (1,0, Primary!, NotModified!) Se la mia memoria è corretta che imposterà tutte le colonne per la prima riga su NotMofidied !. È inoltre possibile eseguire un ResetUpdate() o recuperare i dati.

spero che questo aiuti. Rich

2

Questo di solito significa che alcune colonne sono state incluse nell'aggiornamento in cui la clausola viene aggiornata da qualche altra parte, ad esempio tramite un trigger. un'altra causa include il fatto che la stringa vuota non è impostata per le string colonne quando si parla con oracle. oracle converte qualsiasi stringa vuota inviandola a null, quindi un successivo aggiornamento non troverà la stessa riga a meno che tu non dica a pb di considerarlo nullo. guarda le colonne che hai detto a pb di includere nella clausola where (nelle specifiche di aggiornamento) e assicurati che siano davvero colonne che devi avere lì.

+0

+1 per il controllo "stringa vuota è nulla" .... risolto per me –

1

Ciò può verificarsi anche quando sono presenti due righe di finestre di dati che aggiornano la stessa riga o righe del database.

(A non-così buono) Esempio:

La tabella ha alcuna chiave primaria, ma DataWindow utilizza il DateOfBirth.

 
    Name:   Dennis Miller 
    DateOfBirth: 19531103 
    Vocation:  comedian 
 
    Name:   Kate Capshaw 
    DateOfBirth: 19531103 
    Vocation:  actress 

noti che Dennis e Kate hanno lo stesso DateOfBirth.

Cerchiamo di presumere che questi cambiamenti sono fatti

 
    Name:   Mr. Dennis Miller 
 
    Name:   Ms. Kate Capshaw 

Quando viene richiamato dw_1.update(), appare questo messaggio:

 
    "Row changed between retrieve and update" 

perché ogni riga è stato aggiornato due volte, prima con 'Mr. Dennis Miller 'e poi con' Ms. Kate Capshaw '

+0

In questo caso è possibile aggiungere [genere e codice postale] (http://epic.org/privacy/reidentification/) alla chiave. –

0

Mi rendo conto che questa è una vecchia domanda, ma ho pensato di aggiungere la mia soluzione nel caso in cui aiuti qualcuno. Nel mio caso, la finestra di dati stava emettendo un'istruzione UPDATE e quando quell'istruzione veniva eseguita in SQL management studio, le colonne restituivano corrispondevano a ciò che si sarebbe dovuto prevedere. Tuttavia, la query ha mostrato due volte dove (1 riga (s) interessati).Un trigger stava aggiornando una riga non correlata alla tabella che si stava aggiornando. L'aggiunta di SET NOCOUNT ON a quell'attivazione ha dato come risultato 1 istanza in cui (1 riga (e) interessata) e la riga modificata tra recupero e aggiornamento è stata risolta.

0

Un'altra possibilità è che la definizione della colonna del datawindow non corrisponde alla definizione della colonna del database.

Esempio:

  1. ColumnA è definito nel database come char (10)

  2. DataWindow è costruito con Columna come char (10)

  3. Columna è alterata a char (20) nella banca dati

  4. i dati vengono aggiunti esternamente alla colonna A con più di 10 caratteri.

  5. DataWindow recuperare tronca a 10 caratteri (con o senza errore a seconda delle impostazioni dell'applicazione.)

  6. cancellare riga/aggiornamento può produrre "fila cambiato tra recuperare e aggiornare"

0

Questo comportamento è monitorato dalle 'Proprietà di aggiornamento' della tua finestra di dati e più specificamente dalla parte 'Clausola Where per Update/Delete'. Questo controlla il 'dove' la clausola che verrà utilizzato da Powerbuilder su updating.deleting, come si potrebbe verificare utilizzando l'evento SQLPreview del DataWindow:

  1. colonne chiave: solo le colonne chiave vengono utilizzati nel dove la clausola. Se lo usi, hai il rischio che alcune colonne siano state modificate altrove (non necessariamente da PowerBuilder) tra il tuo recupero e il tuo aggiornamento. Solo l'ultimo aggiornamento rimarrà nel DB. Ovviamente, se le colonne delle chiavi sono state modificate, verrà visualizzato il messaggio 'Row changed'.
  2. Colonne chiave e aggiornabili: in cima alle colonne chiave, si aggiungono tutte le colonne aggiornabili, come definite immediatamente sotto, nella casella "Colonne aggiornabili". Ogni volta che una colonna è stata modificata (anche in questo caso non è necessario utilizzare Powerbuilder), la riga non verrà recuperata e verrà visualizzato il messaggio "Riga modificata". In molti casi, questo è eccessivo.
  3. Colonne chiave e modificate: solo le colonne modificate per la riga specifica vengono aggiunte alla chiave.
    Ora spetta a voi scegliere uno di questi, in base al contesto specifico dell'applicazione.
Problemi correlati