“I dati sono stati modificati” errore quando passo dalla maschera principale in sotto forma

Sto migrazione di un database di Access a SQL Server utilizzando SQL Server Migration Assistant (SSMA). L’Accesso dell’applicazione continuerà ad essere utilizzato, ma con le tabelle collegate, invece di quelli locali.

Ho incorrere in un problema durante la fase di post-test di migrazione con un modulo che contiene diverse sotto forme.

Fasi di sperimentazione:

1) Modificare un campo nel form principale;

2) spostare l’attenzione su un campo della form;

3) Tentare di modificare il campo nel form.

Risultato: Un messaggio di errore compare: “I dati sono stati modificati. Un altro utente ha modificato il record e salvato le modifiche prima si è tentato di salvare le modifiche.”

Una volta il messaggio di errore è respinto in campo nel sub modulo può essere modificato. Se il campo nel form principale non viene modificato il sub modulo può essere modificato senza il messaggio di errore.

Le idee su cosa potrebbe essere causato questo errore?

Ho cercato di salvare il record della maschera principale di Immettere un gestore di eventi per il sub forma di controllo sul form principale (cioè questo evento si verifica nella maschera principale, all’ingresso di controllo che contiene il form, non il sub la forma). Non fa alcuna differenza. Ho cercato di riottenere la forma principale nella stessa sotto forma di controllo, Immettere l’evento, ma che non funziona – di riottenere la forma principale si sposta l’attenzione dal sub form, in modo che non può essere modificato.

MS forum Mi ha suggerito.Genitore.Requery in After_Update evento del form. Che non ha funzionato neanche.

SQL Profiler è una singola istruzione update, l’aggiornamento della tabella sottostante form principale, quando io passo nel form. Non ci sono altre dichiarazioni di colpire il database di modificare i dati.

Una cosa interessante che ho notato: L’Origine Record per il modulo principale è in realtà un’istruzione select che unisce due tabelle. La forma principale contiene campi che possono aggiornare le colonne in ciascuna delle tabelle nell’Origine Record. Modifica dei campi nel form principale che aggiorna la tabella figlio nel rapporto non causa “sono stati cambiati i dati di errore”. L’errore si verifica solo quando la modifica di campi che aggiorna la tabella padre nel rapporto. Ho provato campi aggiornamento colonne diverse in ciascuna delle due tabelle. I risultati sono coerenti: la Modifica del record della tabella principale causa l’errore, la modifica del record della tabella figlio non.

Il collegamento tra il sub e il modulo di form principale si unisce a una colonna nella sotto forma di tabella una colonna nella tabella figlio nella maschera principale Origine di Record.

A proposito, le tabelle del Record della maschera principale Fonte in realtà sono accomunati in un rapporto di 1:1 (un record nella tabella figlio per ogni record della tabella padre). La tabella figlio è solo una tabella di estensione per la tabella padre.

Io personalmente non progettare il sistema come questo, se ero a partire da zero, ma è quello che ho avuto modo di lavorare con e sto sperando che ci sia qualche ragionevolmente soluzione semplice che non richiede una riprogettazione delle tabelle o delle forme (data la forma principale e sotto ogni forma, hanno più di 100 controlli).

Hai provato a creare una Vista sul Server SQL che restituisce le stesse colonne come la forma principale del Record corrente Origine, collegamento, che vista come una “tabella collegata” in Accesso e quindi l’utilizzo di che come Origine Record per il form principale?
Il rapporto di 1:1 sembra sospetto a me da l’errore che ti permette di procurarti riflette un utente simultanee di errore più probabile rilasciato da ODBC. Forse si può cercare di far cadere il rapporto di 1:1 solo per vedere se che isola l’errore.
Thompson: Provato, utilizzando un trigger Instead Of a trattare con gli aggiornamenti attraverso la vista. Trovato ho dovuto aggiungere un indice univoco per la tabella collegata Accesso sul lato per permettere il record da aggiornare. Modulo funziona esattamente come in origine, con la finestra di dialogo di errore durante l’aggiornamento di campi che la mappa di una tabella di SQL Server, ma nessun problema durante l’aggiornamento di campi di mappa all’altra tabella. Quando ho chiudere la finestra di dialogo di errore posso quindi aggiornare i campi corrispondenza con la tabella di problema, come prima. Così ora ho il sospetto che deve avere qualcosa a che fare con le proprietà dei singoli controlli del form.

OriginaleL’autore Simon Tewsi | 2013-04-25

3 Replies
  1. 11

    Dopo molti tentativi ed errori ho risolto il problema. Immettere un gestore di eventi per il sub forma di controllo sul form principale, ho riesegue una query sul sub stesso.

    ad esempio, Sulla maschera principale:

    Private Sub Subform1_Enter()
        Me.Subform1.Form.Requery
    End Sub
    

    Non so perché questo funziona, solo che lo fa.

    +1 Grazie per la condivisione della scoperta.

    OriginaleL’autore Simon Tewsi

  2. 4

    Questo accade quando un aggiornamento di record in una tabella, ma l’origine record della maschera principale non è stato aggiornato per riflettere il cambiamento, in modo che l’Accesso riceve informazioni contrastanti e che pensa che il record è stato modificato. Vedi anche: http://support.microsoft.com/kb/302492

    La lettura che supportano l’articolo sembra che ho avuto quasi il problema opposto: ho modificato la forma principale prima di trasferirsi nella sottomaschera. Ho il sospetto che mi potrebbe aver modificato la risposta di quell’articolo per risolvere il mio problema: Nell’evento AfterUpdate gestore per il controllo nella maschera principale ho potuto aggiungere Me.Subform1.Forma.Requery. Non ho provato, ma ho il sospetto che avrebbe funzionato come pure l’aggiunta che la linea per la sottomaschera evento di Invio del form principale (che è quello che ho fatto per risolvere il problema).

    OriginaleL’autore LauraNorth

  3. 1

    Risolvere questo problema tramite la scrittura AfterUpdate forma-evento come questo:

    Private Sub Form_BeforeUpdate(Cancel As Integer)
        cSQL = "update UnderlinedTable set Field1=" & Me.Controls("Field1") & _
            ", Field2=" & Me.Controls("Field2") & _ ' and all other fields in your form
            " where PrimaryKey=" & Me.Recordset.Fields("PrimaryKeyField")
        ' here command to SQL server that executes this cSQL string
        Me.Requery
        Cancel = True 'stop Access updating
    end sub
    

    È possibile essere scritta con universale BeforeUpdate forma-funzione di evento che genera automaticamente l’Aggiornamento dichiarazione basata su form.recordsource e cambiato campi del modulo che può essere richiamato da tutti AfterUpdate forma-gli eventi passando forma come parametro. Ho fatto questo per me.

    OriginaleL’autore Rosen Nikolov

Lascia un commento