In merito all'inconveniente verificatosi:
Philcattivocarattere ha scritto:
Resta però l'interrogativo di partenza. Grrrrr.
Da una breve visione del demo allegato, si osserva che nel report principale (rptMain) la casella di testo (testo10) con anteposta etichetta "SubTotale2002", ha origine controllo:
=IIf(subOrdini.Report.HasData=Vero;subOrdini.Report!TotFreight;0)
e funziona in tutte le versioni di Access con cui ho effettuato il test (2000, 2002, 2003, 2007 e 2013);
mentre la casella di testo (testo12) con anteposta etichetta "SubTotale2013" (ove nella versione 2013, rispetto alla 2002, viene effettuata una conversione automatica con i nomi degli oggetti e proprietà fra parentesi quadre) la quale ha origine controllo:
=IIf([subOrdini].[Report].[HasData]=Vero;[subOrdini].[Report]![TotFreight];0)
confermo che NON funziona in Access 2000, 2002, 2003, 2007 e 2013 in quanto fornisce, appunto, "#Nome" sintomo di un errore nell'origine controllo.
Tale errore permane nelle nuove versioni in ACCDB mentre con le vecchie versioni MDB se si genera nuovamente l'origine controllo (anche assegnando la forma degli oggetti posti fra parentesi quadre)
=IIf([subOrdini].[Report].[HasData]=Vero;[subOrdini].[Report]![TotFreight];0)
viene effettuato correttamente il calcolo proveniente dal sottoreport.
Questo indica che l'operazione di auto correzione che avviene, in MDB, può accedere al subreport mentre ciò non avviene in ACCDB (permanendo l'errore sull'oggetto).
Infatti l'errore "#Name" si verifica quando Access non trova i campi associati al controllo, in quanto ogni oggetto viene memorizzato in una mappa, con il suo nome e un identificativo univoco in modo da accedere attraverso un puntatore alle proprietà e metodi associati.
Quando un oggetto viene salvato, il suo nome nella mappa viene aggiornato in modo da riflettere il riferimento al nuovo oggetto.
Quindi è da ritenere che l'operazione automatica che avviene variando l'origine del controllo, in MDB, funzioni perché viene risolto l'accesso al subreport ed eseguito pertanto il codice associato.
Come ulteriore verifica in ACCDB si può notare che indipendentemente dalla verifica della presenza dei dati (con metodo Report.HasData) anche presentare il semplice risultato del controllo nel sottoreport (TotFreight) questo non viene soddisfatto e si ottiene sempre "#Name".
Ciò è sintomo di una diversa gestione della sequenza e gerarchia nella gestione del modello ad oggetti di generazione del report e subreport.
Ciò potrebbe risiedere nelle operazioni di autocorrezione che Access pone in essere al momento della imputazione dall'origine del controllo (che seppure permettono la visualizzazione del controllo calcolato nel subreport) non aggiornano correttamente il puntatore all'oggetto.
Ad ulteriore verifica è da evidenziare che la variazione da te apportata, applicabile anche su evento Format
Private Sub Corpo_Format(Cancel As Integer, PrintCount As Integer)
If Me!subOrdini.Report.HasData Then
Me!NomeTxtBox.Value = Me!subOrdini.Report!TotFreight.Value
Else
Me!NomeTxtBox.Value = 0
End If
End Sub
che determina il corretto totale del subreport (nella versione ACCDB) conferma che nella formattazione del report questo accede al campo calcolato nel sottoreport e produce il valore esatto (quindi accede all’oggetto) mentre ciò non avviene nella interpretazione dell’origine del controllo.
A corollario, se può essere utile ad un lettore, dal momento che con le varie versioni di Access si sono individuate tutta una serie di problematiche legate alla totalizzazione in un main report con i dati di un subreport presento alcuni link:
- autocorrezione
https://support.office.com/en-sg/article/Set-name-AutoCorrect-options-b475af37-dcf8-477e-a9d8-32ca9c1d4623
http://allenbrowne.com/bug-03.htm
http://www.utteraccess.com/forum/index.php?showtopic=1753967
- errore #Name? in un controllo
http://answers.microsoft.com/en-us/office/forum/office_2010-access/name-appears-in-a-calculated-form-field-in-access/9861c9e7-a440-4ef2-9842-7909752b4fa3?db=5&auth=1
- diversità nel calcolo fra report (o maschera) principale che riprende un sottoreport (o sottomaschera) rilevato con il passaggio da Access 2003 a 2007
http://allenbrowne.com/RecordCountError.htm
- impiego del metodo "HasData" per gestire il sottoreport al fine di verificare se questo abbia dati (in modo da ottenere il totale nel report principale e non l’errore in caso di mancanza di valori del sottoreport)
http://accessdatabasetutorial.com/2014/03/04/microsoft-access-reports-passing-totals-from-a-subreport-into-the-main-report/
http://www.techrepublic.com/blog/microsoft-office/how-to-show-access-subreport-totals-in-main-report/
http://www.tek-tips.com/viewthread.cfm?qid=65555
- impiego della sintassi completa nella gerarchia degli oggetti
https://support.microsoft.com/en-us/kb/11335
- utilizzo della funzione Val
https://support.microsoft.com/en-us/kb/20883
- disporre un ulteriore Subtotale nel Subreport nella sezione Group footer.
http://www.utteraccess.com/forum/subreport-grand-total-ma-t2001534.html
http://www.access-programmers.co.uk/forums/showthread.php?t=203250
- gestione dell'errore (con IsError)
http://www.pcreview.co.uk/threads/reports-sub-reports-running-sum-and-no-data.4040275/
- accesso alle variabili di totalizzazione (in quanto Access non memorizza i valori calcolati)
https://support.microsoft.com/en-us/kb/11335