2013-04-25 22 views
5

Sto migrando un database di Access a SQL Server utilizzando l'Assistente migrazione SQL Server (SSMA). L'applicazione Access continuerà ad essere utilizzata ma con tabelle collegate anziché locali.Errore "I dati sono stati modificati" quando si passa dalla maschera principale alla sottomaschera

Ho incontrato un problema durante il test di post-migrazione con un modulo che contiene diverse sotto-forme.

Testing passi:

1) modificare un campo nella maschera principale;

2) Spostare lo stato attivo su un campo nella sotto-forma;

3) Tentare di modificare il campo nel modulo secondario.

Risultato: viene visualizzato un messaggio di errore: "I dati sono stati modificati. Un altro utente ha modificato questo record e ha salvato le modifiche prima di tentare di salvare le modifiche."

Dopo aver eliminato il messaggio di errore, è possibile modificare il campo nel modulo secondario. Se il campo nel modulo principale non è modificato, il modulo secondario può essere modificato senza il messaggio di errore.

Qualche idea su cosa potrebbe causare questo errore?

Ho provato a salvare il record del modulo principale nel gestore eventi Enter per il controllo del sottomodulo nel modulo principale (ovvero questo evento si verifica nel modulo principale, quando si immette il controllo che contiene il modulo secondario, non sul sotto forma stessa). Non fa alcuna differenza Ho provato a rieseguire il modulo principale nello stesso controllo di sottomodulo. Inserisci evento, ma non funziona: la compilazione del modulo principale sposta l'attenzione dal modulo secondario in modo che non possa essere modificato.

Un forum MS ha suggerito Me.Parent.Requery nell'evento After_Update del modulo secondario. Neanche questo ha funzionato.

SQL Profiler mostra una singola istruzione di aggiornamento, aggiornando la tabella sottostante il modulo principale, quando passo al sottomodulo. Non ci sono altre dichiarazioni che colpiscono il database che modifica i dati.

Una cosa interessante che ho notato: l'origine record per il modulo principale è in realtà un'istruzione selezionata che unisce due tabelle. Il modulo principale contiene campi che possono aggiornare le colonne in ciascuna delle tabelle nell'origine record. La modifica dei campi nel modulo principale che aggiorna la tabella figlio nella relazione non causa l'errore "i dati sono stati modificati". L'errore si verifica solo quando si modificano i campi che aggiornano la tabella padre nella relazione. Ho provato i campi che aggiornano diverse colonne in ciascuna delle due tabelle. I risultati sono coerenti: la modifica del record nella tabella padre causa l'errore, non la modifica del record nella tabella figlio.

Il collegamento tra il modulo secondario e il modulo principale unisce una colonna nella tabella del modulo secondario a una colonna nella tabella figlio nella sorgente record del modulo principale.

A proposito, le tabelle nella forma principale Origine record vengono effettivamente unite in una relazione 1: 1 (un record nella tabella figlio per ogni record nella tabella padre). La tabella figlio è solo una tabella di estensione per la tabella padre.

Personalmente non progetterei il sistema in questo modo se stavo partendo da zero ma è quello con cui ho lavorato e spero che ci sia una soluzione ragionevolmente semplice che non richiederà una riprogettazione importante di le tabelle o i moduli (dato il modulo principale e il modulo secondario hanno ciascuno più di 100 controlli).

+1

Si è tentato di creare una vista su SQL Server che restituisce le stesse colonne dell'origine record corrente del modulo principale, collegando tale vista come una "tabella collegata" in Access e quindi utilizzando * that * come Registra fonte per il modulo principale? –

+0

La relazione 1: 1 mi sembra sospetta poiché l'errore che si ottiene riflette un errore utente simultaneo molto probabilmente emesso da ODBC. Forse puoi provare a eliminare la relazione 1: 1 solo per vedere se questo isola l'errore. –

+0

@Gord Thompson: l'ho provato, utilizzando un trigger invece di affrontare gli aggiornamenti attraverso la vista. Trovato ho dovuto aggiungere un indice univoco alla tabella collegata sul lato di accesso per consentire ai record di essere aggiornabili. Il modulo funziona esattamente come originariamente, con la finestra di errore quando aggiorno i campi che si associano a una tabella di SQL Server, ma nessun problema quando aggiorno i campi che si associano all'altra tabella. Quando cancello la finestra di dialogo degli errori, posso aggiornare la mappatura dei campi alla tabella dei problemi, come prima. Quindi ora sospetto che debba avere qualcosa a che fare con le proprietà dei singoli controlli del modulo. –

risposta

6

Dopo molte prove ed errori ho risolto il problema. Nel gestore di eventi enter per il controllo del sotto modulo sul modulo principale, ho richiesto il modulo secondario stesso.

ad esempio nella maschera principale:

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

non so il motivo per cui questo funziona, solo che lo fa.

+0

+1 Grazie per aver condiviso la tua scoperta. –

3

Ciò accade quando un record viene aggiornato in una tabella, ma l'origine record del modulo principale non è stata aggiornata per riflettere la modifica, pertanto Access riceve informazioni in conflitto e pensa che il record sia stato modificato. Vedere anche: http://support.microsoft.com/kb/302492

+0

Leggendo l'articolo di supporto sembra che abbia quasi il problema inverso: ho modificato il modulo principale prima di passare alla sottomaschera. Ho il sospetto che avrei potuto modificare la risposta da quell'articolo per risolvere il mio problema: nel gestore di eventi AfterUpdate per il controllo nel modulo principale avrei potuto aggiungere Me.Subform1.Form.Requery. Non l'ho provato, ma ho il sospetto che avrebbe funzionato bene come aggiungere quella linea all'evento Enter della sottomaschera sul form principale (che era quello che ho fatto per risolvere il problema). –