[VB.NET] Errore su Entity Framework con MySQL: tabella non trovata su eliminazione record correlati

[Veronica80]

il codice completo è questo:

  Dim myDB As EF_DB = creaMyDB()
        Try
            Dim lstToDel As List(Of movimenti) = myDB.movimenti.Where(Function(m) idToDel.Contains(m.id_Mov)).ToList
            myDB.movimenti.RemoveRange(lstToDel)
            myDB.SaveChanges()
            MsgBox("Movimenti Eliminati", MsgBoxStyle.Information, "Operazione Effettuata")
            out = True
        Catch ex As Exception
            errMsg(ex)
        Finally
            killMyDB(myDB)
        End Try

le 2 sub che richiamo (creaMyDB e killMyDB) sono queste:

    Function creaMyDB() As EF_DB
        Return New EF_DB
    End Function

    Function killMyDB(ByVal myDB As EF_DB) As Boolean
        myDB.Dispose()
        Return IsNothing(myDB)
    End Function

[alka]

Table 'finanze.finanze.movimenti' doesn't exist"

Non è che questi record lasciano degli orfani all'interno del DB, ossia record che puntano a essi e così non hanno più a disposizione il figlio nella relazione?

il codice completo è questo [...]

Il valore di ritorno booleano non ti serve a nulla: se si verifica un errore, è l'eccezione che deve "uscire" e veicolare questa condizione, gestendola all'esterno della procedura anche con la visualizzazione di un messaggio; inserendola qui, sei costretta sempre a testare il valore booleano di ritorno complicando il codice, e a gestire in un sol modo l'errore, mentre magari all'esterno potresti voler cambiare idea o fare qualcosa di più.

le 2 sub che richiamo (creaMyDB e killMyDB) sono queste [...]

Anche queste due sub non ti servono a nulla e complicano soltanto: la prima fa solamente una New senza particolari aggiunte, la seconda chiama Dispose (che è corretto) e restituisce sempre un booleano inutile, anche perché sarà sempre "True" in quanto myDB è diverso da Nothing, sebbene rimanga inutilizzabile poiché hai fatto Dispose() dell'oggetto a cui la variabile fa riferimento, quindi è pure fuorviante.

Semplificare, semplificare, semplificare.

[Veronica80]

Eheheh Alka, tu sei come l'agente Smith di Matrix: hai sempre ragione!

io i booleani li metto sempre perchè ho paura che non venga eseguito qualcosa (tipo il dispose) ma in effetti hai ragione!

Mentre nella prima (dove aggiungo i record) lo metto perchè è una funzione pubblica inserita in un modulo e ci sono delle istruzioni da eseguire nel caso sia true sul form che richiama la funzione! Comunque ora cerco di ragionare meglio e semplificare!

I record incriminati non hanno record figli ma, anzi, sono loro figli. L'unica FK li collega (come figli) a una tabella coi record padre con relazione uno-a-molti, eliminandoli quindi lascio la tabella padre senza figli ma non viceversa...

E' proprio strano...

[alka]

Eheheh Alka, tu sei come l'agente Smith di Matrix: hai sempre ragione!

Se non fosse che fa una brutta fine, sarei quasi contento di questo.

io i booleani li metto sempre perchè ho paura che non venga eseguito qualcosa (tipo il dispose) ma in effetti hai ragione!

La presenza (o assenza) di un valore di ritorno booleano non da alcuna sicurezza in più, sotto questo aspetto.

La segnalazione di errori viene fatta tramite il sollevamento di eccezioni, che veicolano l'informazione relativa alla condizione imprevista verificatasi, interrompono l'esecuzione del metodo e fanno risalire il percorso di esecuzione al metodo chiamante, fino a trovare un blocco in cui l'eccezione viene gestita.

Se si vuole garantire l'esecuzione del Dispose(), è sufficiente il Try...Finally oppure il costrutto Using.

Mentre nella prima (dove aggiungo i record) lo metto perchè è una funzione pubblica inserita in un modulo e ci sono delle istruzioni da eseguire nel caso sia true sul form che richiama la funzione! Comunque ora cerco di ragionare meglio e semplificare!

Se il valore è sempre "True", tranne quando si verifica l'eccezione, tanto vale 1) non restituire il valore, 2) nel blocco che chiama la procedura usare Try...Except e gestire nella parte dell'Except la visualizzazione dell'errore e le istruzioni da eseguire in caso di errori, altrimenti lasciare proseguire l'esecuzione del codice con le istruzioni previste in caso di restituzione del valore "True".

I record incriminati non hanno record figli ma, anzi, sono loro figli. L'unica FK li collega (come figli) a una tabella coi record padre con relazione uno-a-molti, eliminandoli quindi lascio la tabella padre senza figli ma non viceversa...

E' equivalente: se questi record puntano ai record rimossi e non vengono modificati, il valore del campo di correlazione non sarà valido e pertanto occorre aggiornarli, o sul DB (specificando cosa fare nella definizione della FOREIGN KEY) oppure tramite Entity Framework, ad esempio scandendo tutte le entità correlate a quella da rimuovere e impostando a Nothing i campi che puntano al record che non esisterà più.

E' proprio strano...

Purtroppo no, direi che è assolutamente normale.

Ciao!

[Veronica80]

Si si tutto chiaro il discorso sulle eccezioni! In effetti mi rendo conto che il mio è stato un'eccesso (inutile) di prudenza che provvederò a rimuovere al fine di alleggerire tutto il codice!

Per gli EF io pensavo che funzionasse come SQL o cari vecchi Dataset dove se eliminavi i record figli il record padre non veniva intaccato (dacchè non ha un campo dipendente da questi ultimi) mi sfugge il passaggio in cui i record (padre) puntano a quelli figli...tant'è che la FK ha i metodi Update e Delete impostati su CASCATA perchè di norma io vado a cascata da padre a figlio e non viceversa (quest'ultima affermazione potrebbe essere interpretata male dai + maliziosi ).

In sostanza non sono sicura di avere capito bene cosa (ma soprattutto PERCHE') dovrei fare!

[alka]

Per gli EF io pensavo che funzionasse come SQL o cari vecchi Dataset dove se eliminavi i record figli il record padre non veniva intaccato (dacchè non ha un campo dipendente da questi ultimi) mi sfugge il passaggio in cui i record (padre) puntano a quelli figli...tant'è che la FK ha i metodi Update e Delete impostati su CASCATA perchè di norma io vado a cascata da padre a figlio e non viceversa

Prova a riportare (molto schematicamente) la struttura del DB (solo le tabelle e i campi principali coinvolti) e la definizione delle chiavi FK, giusto per essere sicuri che rispecchi quella che abbiamo in mente.

[Veronica80]

Allora in sintesi abbiamo una tabella (dati_in_out) padre relazionata con una tabella figlio (movimenti) tramite una FK in questo modo:

Screenshot_1.png

Il campo id_InOut, della tabella padre, e quello idInOut_Mov, della tabella figlio, sono collegati con una relazione "1 a molti" con impostazione "Cascade" sia sull'update che sul delete (dei record padre ovviamente).

Sulla base di queste regole di integrità referenziale io non mi aspetto che qualche campo della tabella padre punti a qualche campo della tabella figlio, bensì l'esatto contrario!

Per questo non capisco in che modo un campo della tabella padre possa rimanere orfano di un dato nel caso cancellassi record dalla tabella figlio.


Un'altra cosa che non riesco a capire è l'errore che ricevo:

Table 'finanze.finanze.movimenti' doesn't exist"

che è lo stesso che ricevevo quando provavo a inserire la stessa entity più volte.
Mi sarei aspettato un errore inerente relazioni ed integrità referenziale invece ogni volta che qualcosa non funziona o sbaglio qualcosa mi dice che la tabella non esiste...

[alka]

Allora in sintesi abbiamo una tabella (dati_in_out) padre relazionata con una tabella figlio (movimenti) tramite una FK in questo modo [...]
Sulla base di queste regole di integrità referenziale io non mi aspetto che qualche campo della tabella padre punti a qualche campo della tabella figlio, bensì l'esatto contrario!

Se la foreign key è sulla seconda tabella, direi che le premesse sono corrette e quanto dici è giusto.

Per questo non capisco in che modo un campo della tabella padre possa rimanere orfano di un dato nel caso cancellassi record dalla tabella figlio.

Da quello che posso vedere, non dovrebbero esserci orfani, quindi la problematica non riguarda questo.

Un'altra cosa che non riesco a capire è l'errore che ricevo:
Table 'finanze.finanze.movimenti' doesn't exist"

Purtroppo da questo punto di vista non posso essere molto d'aiuto perché andrebbe analizzato il database, il modello creato e il codice in quella situazione facendo debug passo per passo e verificando per gradi che ogni step sia stato fatto nel modo giusto e, quando si verifica l'errore, approfondire lo stato degli oggetti in memoria; analogamente andrebbero controllati namespace e altre proprietà degli oggetti generati da EF, la presenza di trigger su database o altre operazioni eseguite fuori dal contesto di EF, insomma bisognerebbe disporre di tutte le risorse coinvolte nella problematica e forzare anche delle convenzioni che non producano mal di pancia legati a messaggi di errore fuorvianti in seguito.

Io adotto metodologie abbastanza rigorose con EF, ma con le informazioni fornite fin qui non riesco purtroppo a diagnosticare (al netto delle ipotesi possibili che ho già fatto) qual è l'origine dei problemi che riscontri con l'ORM.

[Veronica80]

Se la foreign key è sulla seconda tabella, direi che le premesse sono corrette e quanto dici è giusto.


Da quello che posso vedere, non dovrebbero esserci orfani, quindi la problematica non riguarda questo.


Purtroppo da questo punto di vista non posso essere molto d'aiuto perché andrebbe analizzato il database, il modello creato e il codice in quella situazione facendo debug passo per passo e verificando per gradi che ogni step sia stato fatto nel modo giusto e, quando si verifica l'errore, approfondire lo stato degli oggetti in memoria; analogamente andrebbero controllati namespace e altre proprietà degli oggetti generati da EF, la presenza di trigger su database o altre operazioni eseguite fuori dal contesto di EF, insomma bisognerebbe disporre di tutte le risorse coinvolte nella problematica e forzare anche delle convenzioni che non producano mal di pancia legati a messaggi di errore fuorvianti in seguito.

Io adotto metodologie abbastanza rigorose con EF, ma con le informazioni fornite fin qui non riesco purtroppo a diagnosticare (al netto delle ipotesi possibili che ho già fatto) qual è l'origine dei problemi che riscontri con l'ORM.

Si mi rendo conto che se, come pare, il codice è scritto correttamente l'eccezione sicuramente è generata in qualche meandro che tu non puoi vedere (e che io, vista la mia scarsa esperienza, non riesco ad individuare).

Di fatto non riesco a debuggare ciò che fa il saveChanges() non essendo codice scritto da me ma procedure già impostate nel framework...

L'unica cosa che posso provare a fare e creare un nuovo progetto con lo stessdo modello e provare a eseguire l'operazione li dove l'ambiente è ancora vergine (tanto il DB son 3 tabelle di numero non sarà una cosa lunga!).

Grazie lo stesso! Ho fatto cmq tesoro di molti consigli!!!

[Veronica80]

Aggiornamento:

Come preannunciato ho creato un progetto vergine dove ho ricreato il modello EF ma il problema sussiste!

Ora è un po più facile analizzare la situazione dacchè ho solamente:

• Creato un nuovo progetto
• Installato EF 6.4.4 dalla Gestione NuGet
• Installato il connettore MySQL Entity Framework 8.0.25 sempre da NuGet
• Creato il Modello EF usando la funzione Entity Framework Designer da Database
• Modificato il modello di generazione DDL (del mio modello EF) in SSDLToMySQL8.tt (VS)

Tutto il resto l'ho lasciato invariato. E quando provo il codice di removeRange mi da sempre quell'errore...