Errore #Name? in textbox report principale con riferimento a sottorep

di il
4 risposte

Errore #Name? in textbox report principale con riferimento a sottorep

Non è una richiesta d'aiuto classica, quanto una condivisione di un errore di Access di cui ero a conoscenza e che ho approfondito.

Di recente (vedi https://www.iprogrammatori.it/forum-programmazione/access/errore-sharpnome--t52129.html)

ho avuto occasione di ravvivare uno dei tarli che mi tormenta e che risale al 2015

https://www.iprogrammatori.it/forum-programmazione/access/somma-sottoreport-report-t26211.html

Per una sorta di folgorazione mi sono lanciato in una prova abbastanza strana: ho esportato il report con l'errore con il metodo non documentato SaveAsText e ne ho esaminato il contenuto ed ecco qualche spiegazione in più, anche se non risolve l'arcano

La textbox del report principale che punta al totale presente nel sottoreport e creata con Access 2002 ha questo ControlSource

=IIf(subOrdini.Report.HasData=True,subOrdini.Report!TotFreight,0)

La textbox creata con Access 2013 prima ma nulla cambia con Access 365 e che restituisce l'errore #Nome? ha questo ControlSource

=IIf([subOrdini].[Reports].[HasData]=True,[subOrdini].[Reports]![TotFreight],0)

Preciso che l'origine dati è stata creata in entrambi i casi con il generatore di espressioni.

Eccezion fatta per la presenza delle parentesi quadrate di cui non si riesce a liberarsi, la differenza è data dalla presenza nella prima della parola Report (senza la S del plurale inglese) e nella seconda, quella che va in errore, dalla parola al plurale: Reports

Modificando a mano il file di testo esportato da SaveAsText togliendo la “s” finale da Reports, ottenendo così la proprietà ControlSource

=IIf([subOrdini].[Report].[HasData]=True,[subOrdini].[Report]![TotFreight],0)

ed importando poi il file così modificato con LoadAsText, il nuovo report appena creato non riporta più l'errore #Name?

Questo mi porta a pensare che se si riesce ad evitare che Access intervenga con i suoi autocompletamenti dell'origine dati, si riesce ad ottenere quello che fino ad Access 2002 era normale, cioè fare in modo che una textbox nel report principale prenda il valore da una textbox nel sottoreport senza ricorrere a VBA.

Ritornare sulla casella di testo anche solo per fare un Taglia-Incolla dell'origine dati, che nell'interfaccia grafica rimane quindi

=IIf([subOrdini].[Report].[HasData]=True,[subOrdini].[Report]![TotFreight],0)

fa ricomparire l'errore. Esportando nuovamente il report con SaveAsText il ControlSource invece diverso da quanto appare dalla finestra delle proprietà: è tornato “Reports”, con la S finale, portando nuovamente all'errore #Nome? C'è quindi anche difformità tra quanto appare nell'interfaccia grafica da quello che presumibilmente è il vero contenuto del report, se quanto estratto con SaveAsText è rappresentativo della struttura reale.

Vogliamo chiamarlo BUG? Io non ho le competenze tecniche per dirlo. Però questa cosa mi dà un po' di soddisfazione: rispetto al 2015 un passetto avanti l'ho fatto. E' ovvio che non ci si può metter lì ad esportare il report in un testo, a modificare il testo e reimportarlo, avvalendosi tra l'altro di metodi non documentati (SaveAsText e LoadAsText) sui quali non si sa mai fino a che punto è possibile fare affidamento.

Se qualcuno vuole provare con qualcosa di già pronto ecco un file banalissimo. Il report rptMain è quello con errore, prtMainCopia è quello caricato con LoadFromText dopo aver tolto manualmente la S da Reports. Ci sono anche i due file dell'esportazione dei due report ottenuti con SaveAsText.

http://www.fileconvoy.com/dfl.php?id=g13dc44f19d75da9e100050472910f7387b0136496f

(SHA256 del file originale = 1a024262581caed742077e5d9d67c2ef4e1430ec9b7035bdc7e5081d42244493 )

4 Risposte

  • Re: Errore #Name? in textbox report principale con riferimento a sottorep

    Due nuovi test, nell'ottica di avere sempre più informazioni in merito:

    1) Debug.Print dell'origine dati della textbox che dà l'errore #Name? nell'evento Load del report. Il risultato è come quello che c'è nel file che si ottiene con il SaveAsText:

    ControlSource = "=IIf([subOrdini].[Reports].[HasData]=True,[subOrdini].[Reports]![TotFreight],0)"

    con la S in Reports.

    2) Se l'origine dati viene lasciata vuota e si imposta il ControlSource da VBA nell'evento Open con la sintassi giusta, quella senza la S in Report, il controllo valorizza correttamente quanto presente nel sottoreport.

    Ancora una volta, quanto compare da interfaccia grafica non corrisponde al contenuto reale della proprietà ControlSource che se invece viene valorizzata a runtime si comporta correttamente.

  • Re: Errore #Name? in textbox report principale con riferimento a sottorep

    Come mi è stato fatto notare una volta, possibile che nessuno si sia accorto di questo (presunto e tra virgolette) “bug” dal 2015 ad oggi?

    Può essere visto che su una macchina virtuale con SO in inglese ed Access 2021 in inglese funziona tutto perfettamente. Anche le versioni in francese(canadese) e spagnolo non hanno problemi. Il tedesco non lo provo perché non lo conosco, nemmeno lo spagnolo se è per quello ma le parole non sono così difficili da capire conoscendo la GUI italiana.

    Certo che se è tutto collegato ad un diverso comportamento “da traduzione”… che nervoso, grrrr.

  • Re: Errore #Name? in textbox report principale con riferimento a sottorep

    Alcune soluzioni “definitive” al problema (le virgolette su definitive non sono un caso)

    1) Valorizzare la textbox da VBA, ad esempio nell'evento format della sezione in cui si trova la textbox con la consueta sintassi

    If [nomeSottoReport].[Report].[HasData] Then
       txtInReportPrincipale.Value = [nomeSottoReport].[Report].[nomeTextBox].Value
    End If

    2) Lasciare vuota l'origine dati della textbox del report principale e valorizzare la proprietà ControlSource (che è l'origine dati in inglese) tramite VBA nell'evento Open. 

    Private Sub Report_Open(Cancel As Integer)
         nomeTextBox.ControlSource = "=IIf([nomeSottoReport].[Report].[HasData]=True,[nomeSottoReport].[Report]![nomeTextBox],0)"
    End Sub

    Si passa poi a soluzioni radicali, che vanno ad incidere direttamente e in modo permanente sulla proprietà ControlSource della textbox nel report principale e che quindi non richiesono l'uso di VBA nel modulo del report.

    3) Esportare il report con il metodo non documentato SaveAsText

      3.1 Da finestra immediata

    Application.SaveAsText acReport, "nomeReportPrincipale", "Percorso\NomeFile.txt"

       3.2 Aprire con un editor di testo (no Word per capirci) il file, cercare la riga con la proprietà ControlSource della textbox e modificare manualmente togliendo la s da [Reports]

    ...
    Begin TextBox
    ...
    Name ="NomeTextBox"
    ControlSource ="=IIf([nomeSottoReport].[Report].[HasData]=True,[nomeSottoReport].[Report]![nomeTextBox],0)"

       3.3 Importare il report con il metodo LoadFromText (automaticamente sostituisce il report già presente). Da finestra immediata

    Application.LoadFromText acReport, "nomeReportPrincipale", "Percorso\NomeFile.txt"

    4) Modificare la struttura del report principale senza usare l'interfaccia grafica ma VBA

      4.1 Da finestra immediata eseguire in serie questi 3 comandi

    DoCmd.OpenReport "nomeReportPrincipale", acViewDesign, , , acHidden
    Reports("nomeReportPrincipale")!nomeTextBox.ControlSource = "=IIf([nomeSottoReport].[Report].[HasData]=True,[nomeSottoReport].[Report]![nomeTextBox],0)"
    DoCmd.Close acReport, "nomeReportPrincipale", acSaveYes

    Per i numeri 3) e 4), ogni modifica manuale fatta all'origine dati della textbox fa ricomparire il problema, anche se sembra di non cambiare niente, tipo fare un Taglia, uscire dalla casella dell'origine dati, ritornare nella casella origine dati e Incolla. Si deve quindi ripartire con la 3) o 4) ex novo.

  • Re: Errore #Name? in textbox report principale con riferimento a sottorep

    Ho chiesto aiuto andando quanto più possibile vicino alla fonte:

    https://answers.microsoft.com/it-it/msoffice/forum/all/errore-nel-salvataggio-dellorigine-dati-di-una/7550826b-5c2c-44d8-9f5d-e2fc8fb7ca1d

    E' intervenuto Karl Donaubauer, noto MVP Access (e che capisce l'italiano, il che non guasta), con una prima risposta:

    > [NomeSottoMaschera]..Scheda![NomeTextBox]

    Si trattava di un vecchissimo bug che avevo segnalato al team Access di Microsoft qualche tempo fa sulla base di una discussione in un newsgroup, quindi è stato risolto nel 2022. È il secondo fix in questo elenco. Pertanto, non dovrebbe più essere presente nelle versioni ragionevolmente recenti di Access 2016 e 365. Per le versioni più vecchie di Access (2013 e precedenti) che non sono più supportate, il problema non viene più risolto.


    Quella correzione era più ampia e intendeva di risolvere tutti questi problemi di traduzione eccessiva. Puoi indicare i numeri di build esatti di Access 2016 e 365 in cui trovi l'altro con "Reports"?

    Dopo aver indicato la build in cui ho riscontrato i problemi, in brevissimo tempo ha risposto:

    Ho installato la versione italiana e posso/devo confermare la tua descrizione. Informerò Microsoft che questi problemi sono ancora presenti, almeno nell'Access italiano. Riferirò se ci sono informazioni aggiornate da Microsoft al riguardo.

    aggiungendo, dopo nemmeno 24 ore:

    Il team Access di Microsoft ha già confermato che puo ricreare i due problemi nella versione attuale e quindi la correzione citata non ha risolto il problema di "..Scheda" come credevo. Speriamo che risolvano presto i problemi.

    Quindi ora nel posto dove conta sono al corrente del/i problema/i.

    Dai che me la tolgo dalla testa questa cosa che rode dal 2015.

Devi accedere o registrarti per scrivere nel forum
4 risposte