Variabile pubblica: impossibile assegnare un valore all'oggetto

[mantro]

Sto diventando pazzo. Due giorni che tribolo con lo stesso problema.

In un modulo standard dichiaro come Pubbliche 3 variabili stringa:
EserCorr, EserPrec, EserSucc richiamate abbastanza spesso dalle numerose
maschere del db (da qui il motivo 'Pubbliche').

Mentre EserCorr ed EserPrec mantengono regolarmente il loro valore,
appena apro una maschera (Preventivi) la var. EserSucc è NULLA. Non dà
errore e la procedura prosegue come se niente fosse.
Se tento di valorizzarla ecco il messaggio in oggetto numero -2147352567
(80020009).
Ho riscritto quasi tutto il codice della form, ho fatto il debug
passo-passo con F8, ho compilato il codice nell'editor dal menù debug >
compila Database1 (lo uso in caso di difficoltà perché mi tira sempre
fuori qualche str...), ho, ovviamente, guardato su internet se trovavo
qualcosa di chiarificatore, ho perfino cambiato il nome alla variabile
pensando che al mio PC non gli piacesse... nisba... buio assoluto!
Sono già cotto a puntino e pronto per la neuro, ma prima che quei
signori in camice bianco arrivino, qualcuno può suggerirmi qualcosa di
drasticamente utile?
Grazie.

P.S. Pardòn: A2010 32bit su Win10 64bit

[Alessandro Cara]

Il 19/09/2016 18:57, mantro ha scritto:
> Sto diventando pazzo. Due giorni che tribolo con lo stesso problema.

Generalmente Access ha sempre ragione.
Sei sicuro che sia dovuto a quella variabile?
Fare un copia incolla del pezzo di codice che ritieni in
errore non sarebbe male.
Segnalando la istruzione che lo provoca.

--
ac (x=y-1)
Aborro il Killfile
(La violenza e' l'ultimo rifugio degli incapaci -Salvor Hardin-)

[mantro]

Il 19/09/2016 20:36, Alessandro Cara ha scritto:
> Il 19/09/2016 18:57, mantro ha scritto:
>> Sto diventando pazzo. Due giorni che tribolo con lo stesso problema.
>
> Generalmente Access ha sempre ragione.

È quello che dico sempre anch'io agli altri soprattutto quando sono
incazzati...

> Sei sicuro che sia dovuto a quella variabile?
> Fare un copia incolla del pezzo di codice che ritieni in
> errore non sarebbe male.
> Segnalando la istruzione che lo provoca.
>

Non c'è nessun codice particolare. Comunque:

Private Sub Form_Open(Cancel As Integer)
Dim sSql As String, sumTab As Single
Dim rs As DAO.Recordset, noDivZero As Single

On Error GoTo errsub
'cancella eventuali dati esistenti
sSql = "DELETE tblTmpPrev.* FROM tblTmpPrev;"
CurrentDb.Execute sSql
sSql = "INSERT INTO tblTmpPrev ( Esercizio, Tab, Descr, Spesa,
EserSucc, Variaz, Prev ) " _
& "SELECT tblBase.Esercizio, tblBase.Tab, tblBase.Descr,
Sum(tblBase.Debito) AS Spesa, " _
& "'" & EserSucc & "' AS EserSucc, CSng(0) AS Variaz,
Sum(tblBase.Debito) AS Prev " _
& "FROM tblBase " _
& "GROUP BY tblBase.Esercizio, tblBase.Tab, tblBase.Descr;"
CurrentDb.Execute sSql

Funziona così: all'avvio si apre la form principale che contiene un
controllo 'spostamento', che non è altro come un controllo a schede che
già conoscevamo. Premendo uno dei pulsanti in colonna sulla sinistra
visualizza la form interessata, né più né meno come fa un controllo a
schede. Funziona tutto. Quando però premo il pulsante per visualizzare
frmPreventivi e parte la routine sopra esposta, la variabile EserSucc è
Null mentre un miliardesimo di secondo prima era ancora valorizzata. Se
imposto una riga tipo EserSucc="2016-17" appare il msg descritto nel
posto precedente. Questo avviene anche se tento di valorizzare la
variabile nella finestra immediata.
Nota che se invece cambio, anche manualmente, il valore di EserCorr ed
EserPrec tutto funziona come deve funzionare.
Riesci a capire qualcosa, p...ca v...ca?!?!?

[Alessandro Cara]

Il NULL /non/ dovrebbe dare problemi poiche' fai questa concatenazione
& "'" & EserSucc & "' AS EserSucc.. che male che vada diventa
& "'' AS EserSucc..
Non ho capito pero' dove prende /quello/ errore.
Non sulla execute! E non sulla concatenazione! Immagino
Il fatto che tu abbia cambiato nome alla variabile ed hai ancora errore
esclude che ci sia una variabile locale dello stesso nome ed hai
giurato che le tre variabili sono stringhe.

[mantro]

Ale ti ringrazio per l'attenzione (sono diversi anni che seguo questo
gruppo ed ho sempre fatto tesoro delle indicazioni tue e degli altri).
Ma, guarda, un rompicapo come questo non mi era mai capitato.
Questa stramaledetta variabile (è stringa, te lo assicuro) mantiene il
valore nel momento in cui si apre la maschera (evento 'su apertura'), ma
diventa NULL quando si esegue l'INSERT INTO, e non si capisce il perché.
Anche su internet non c'è casistica se non per quanto riguarda questo
errore riferito a controlli e/o maschere.
Se non trovo una soluzione devo ritornare alla prima stesura che era
quella di memorizzare questi tre valori in una piccola maschera nel FE,
ma questo metodo mi comporta una marea di DLookUp da usare in ogni
routine in cui mi serve il dato. Bah, pazienza... grrr...!!! :-(

In ogni caso sempre un caloroso grazie a te e a tutto il ng.

mantro

--

[Karl Donaubauer]

Salve,

mantro:
>>> ...

>>> Private Sub Form_Open(Cancel As Integer)

>>> ...

>>> 'cancella eventuali dati esistenti
>>> sSql = "DELETE tblTmpPrev.* FROM tblTmpPrev;"
>>> CurrentDb.Execute sSql
>>> sSql = "INSERT INTO tblTmpPrev ( Esercizio, Tab, Descr, Spesa,
>>> EserSucc, Variaz, Prev ) " _
>>> & "SELECT tblBase.Esercizio, tblBase.Tab, tblBase.Descr,
>>> Sum(tblBase.Debito) AS Spesa, " _
>>> & "'" & EserSucc & "' AS EserSucc, CSng(0) AS Variaz,
>>> Sum(tblBase.Debito) AS Prev " _
>>> & "FROM tblBase " _
>>> & "GROUP BY tblBase.Esercizio, tblBase.Tab, tblBase.Descr;"
>>> CurrentDb.Execute sSql
>>>

>>> ...Quando però premo il pulsante per visualizzare

>>> frmPreventivi e parte la routine sopra esposta, la variabile EserSucc è
>>> Null mentre un miliardesimo di secondo prima era ancora valorizzata. Se
>>> imposto una riga tipo EserSucc="2016-17" appare il msg descritto nel
>>> posto precedente. Questo avviene anche se tento di valorizzare la
>>> variabile nella finestra immediata.
>>> Nota che se invece cambio, anche manualmente, il valore di EserCorr ed
>>> EserPrec tutto funziona come deve funzionare.
>>> Riesci a capire qualcosa, p...ca v...ca?!?!?

Una variabile del tipo stringa non puo mai essere Null. Vuota vuol dire
stringa vuota o "" o vbNullString.

È meglio di nominare le variabile in un modo particolare/sicuro di
evitare confusioni. Nel tuo codice si vede che esiste un campo tabella
dello stesso nome "EserSucc". Forse l'errore viene da confusioni nel
contesto dove lo usi (maschera o codice). Hai scritto che hai provato un
nome diverso ma non quale. Prova con un nome come "strEserSucc".

> ...

> Se non trovo una soluzione devo ritornare alla prima stesura che era
> quella di memorizzare questi tre valori in una piccola maschera nel FE,
> ma questo metodo mi comporta una marea di DLookUp da usare in ogni
> routine in cui mi serve il dato.

Io invece persino preferisco caselle di testo (spesso invisibile) sulla
maschera di avvio/principale, cioè switchboard, dell'applicazione.
Diverso delle variabile pubbliche è sicuro che hanno un valore anche
dopo un errore nel codice.

Uso funzioni pubbliche che prendono i valori dalla maschera. Poi
dapertutto nell'applicazione (espressioni di query, maschere ecc. o
codice) chiamo queste funzioni.

--
Ciao
Karl
*********
Access FAQ: http://www.donkarl.com/it

[mantro]

Grazie Karl, sempre cortese come al solito. :-)
Alle txtbox nascoste, sinceramente, non avevo pensato. È una possibilità
che devo valutare per le numerose chiamate occorrenti.
Il ricorso a funzioni pubbliche lo faccio abbastanza spesso proprio su
tuo suggerimento in risposta a vari quesiti.
Solo che, questa volta, pensavo di aver scoperto l'acqua calda usando
variabili pubbliche. Ma guarda in che casino sono andato a mettermi!!

[Alessandro Cara]

E' una form di tipo dialog?
Ricordati che se non lo e' esegue l'evento ma poi continua ad eseguire
il codice dell'eventuale chiamante.

[mantro]

Non è una form; ho sbagliato a scrivere; è una tabella.
Mi spiego. Quando devo ricorrere spesso agli stessi dati, come in questo
caso in cui ho bisogno di usare di frequente il valore dell'esercizio
corrente, precedente o successivo, creo in locale nel FE una
semplicissima tabella che mi tiene memorizzati questi dati.
C'è ovviamente un aggiornamento o ad ogni avvio del programma oppure
durante lo stesso se si dovesse rendere necessario. Si tratta
praticamente di un solo record.
Il problema (se problema si può definire) è che devo usare un DLookUp
ogni volta che una routine ha bisogno di questi dati.
Pensavo di accorciare il lavoro con le variabili pubbliche, ma visto il
ginepraio...

[Alessandro Cara]

Si ma quel codice da dove lo lanci?
Ooops!
Scusa non avevo visto che lo hai sulla Open
Vabbe' io non uso la tua struttura (e neanche quella di Karl)
ma non ho /mai/ avuto problemi con le Public di qualsiasi tipo
Tu mi stai dicendo che mettendo un breakpoint, che ne so,
ad esempio sulla On Error EserSucc e' impostata e che, invece,
se guardi poi in sSql dopo averla valorizzata con la INSERT
trovi il valore vuoto?
Hai scritto che usi il debugger.

Non ci credo neanche se lo vedo ;-)

[mantro]

[CUT]

>
> Si ma quel codice da dove lo lanci?
> Ooops!
> Scusa non avevo visto che lo hai sulla Open
> Vabbe' io non uso la tua struttura (e neanche quella di Karl)
> ma non ho /mai/ avuto problemi con le Public di qualsiasi tipo
> Tu mi stai dicendo che mettendo un breakpoint, che ne so,
> ad esempio sulla On Error EserSucc e' impostata e che, invece,
> se guardi poi in sSql dopo averla valorizzata con la INSERT
> trovi il valore vuoto?
> Hai scritto che usi il debugger.
>
> Non ci credo neanche se lo vedo ;-)

Dunque: (e con dunque non si inizia mai un discorso... insegnavano una
volta a scuola...)

- Apertura programma tramite piccola form popup con due listbox in cui
si sceglie l'esercizio ed il condominio; ci sono già evidenziate due
voci in base ai dati ancora memorizzati in quella tab posta nel FE dalla
chiusura precedente.
- Con il pulsante cmdOK
--> se la selezione del condominio è cambiata, riallego le tabelle (per
non complicarmi troppo la vita ho un BE per ogni condominio),
--> assegno i valori alle variabili pubbliche poste in un modulo standard,
--> chiudo la popup di apertura e apro la form principale che, con un
nome molto fantasioso, ho chiamato frmGestione.

Questa è composta da un ctr di tipo spostamento (che fino ad A2003 non
esisteva, giusto?) con sette pulsanti posti in verticale sulla sinistra.
Ogni volta che premo uno di questi pulsanti posso accedere ad un
ulteriore controllo a schede che mi permette di lavorare sulle form che
mi interessano: anagrafiche, impostazioni, spese, letture, suddivisioni,
ripartizioni ecc. ecc.
Funziona tutto perfettamente, le variabili pubbliche hanno sempre il
loro valore, ma... quando premo il pulsante per aprire il ctrScheda con
due schede (Consuntivi e Preventivi rispettivamente) succede l'inghippo.
Aprendo la frmPreventivi (è il codice che ho postato), la var. EserSucc
NON HA PIù il suo valore, è NULLO! La procedura va in errore ed esce.

Tu dubiti che usi il debbuger! E come no! Ho messo il breakpoint subito
dopo la riga on error. L'errore è il 2424 "Impossibile trovare
l'oggetto" o qualcosa di simile. Ho cancellato praticamente tutta la
SELECT rimettendo tutti gli oggetti uno alla volta,beh... l'oggetto che
manca è proprio lo stramaledetto EserSucc... non esiste più, svanito,
puff!... ma EserSucc esiste ancora, solo che è Nullo, e mi puoi credere,
Ale, che è proprio così! Che ci sia qualcosa di sbagliato ne sono
convinto anch'io, ma cosa? A meno che sia proprio access pronto per la
neuro... cosa comunque di cui ne dubito :-)
Se tento di rivalorizzare EserSucc mi appare l'errore chilometrico di
runtime di cui ho già scritto "Impossibile assegnare un valore all'oggetto".
Una precisazione: questa variabile la uso solo in questo modulo, mentre
le altre due le uso in tutto il programma e funzionano benissimo.
Ora sto riscrivendo tutto il codice per questa maschera e proverò a
mettere la variabile solo in locale, speriamo bene! Ciò non toglie però
che le... pallottole mi stiano girando vorticosamente...

[Alessandro Cara]

Non dubitavo. Hai scritto che lo usi e quindi dovrebbe essere facile
con la esecuzione passo passo e con la /ispezione/ delle variabili
vedere lo stato.

> dopo la riga on error. L'errore è il 2424 "Impossibile trovare
> l'oggetto" o qualcosa di simile. Ho cancellato praticamente tutta la

dopo la riga onError c'e' la delete e tra l'altro perche' la scrivi così:
DELETE tblTmpPrev.* FROM tblTmpPrev;
io ho sempre fatto dei banali
delete from table.......
Non mi risulta che si possano /deletare/ solo alcuni campi ;-)
Anche se la sintassi (mi sembra) lo ammetta

> SELECT rimettendo tutti gli oggetti uno alla volta,beh... l'oggetto che
> manca è proprio lo stramaledetto EserSucc... non esiste più, svanito,
> puff!... ma EserSucc esiste ancora, solo che è Nullo, e mi puoi credere,
> Ale, che è proprio così! Che ci sia qualcosa di sbagliato ne sono
> convinto anch'io, ma cosa? A meno che sia proprio access pronto per la
> neuro... cosa comunque di cui ne dubito :-)

Io credo a tutto quello che scrivi.
Anche se le tre variabili /non/ sono oggetti anche per questo mi sembra
strano che possa venir fuori quella segnalazione specifica.
E , credo di averlo gia' scritto, per come imposti la stringa SQL
se quella variabile e' nulla al piu' hai un valore /empty/ cioe ''
nella stringa risultato.
Hai una option explicit in /tutti/ i moduli?

> Se tento di rivalorizzare EserSucc mi appare l'errore chilometrico di
> runtime di cui ho già scritto "Impossibile assegnare un valore
> all'oggetto".

Hai verificato la situazione subito prima della chiamata?
E poi metti un break direttamente sulla entrata della funzione Open e
riverifica.

> Una precisazione: questa variabile la uso solo in questo modulo, mentre

Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!
Allora hai mandato in giro notizie false e tendenziose ;-)
Da qualche parte fai qualche /stranezza/

> le altre due le uso in tutto il programma e funzionano benissimo.
> Ora sto riscrivendo tutto il codice per questa maschera e proverò a
> mettere la variabile solo in locale, speriamo bene! Ciò non toglie però
> che le... pallottole mi stiano girando vorticosamente...
>
>
>

Perche' non posti lo snip di dove definisci ed inizializzi le variabili?

[mantro]

Cosa vuoi fare. L'ho imparata così...

>
>> SELECT rimettendo tutti gli oggetti uno alla volta,beh... l'oggetto che
>> manca è proprio lo stramaledetto EserSucc... non esiste più, svanito,
>> puff!... ma EserSucc esiste ancora, solo che è Nullo, e mi puoi credere,
>> Ale, che è proprio così! Che ci sia qualcosa di sbagliato ne sono
>> convinto anch'io, ma cosa? A meno che sia proprio access pronto per la
>> neuro... cosa comunque di cui ne dubito :-)
>
> Io credo a tutto quello che scrivi.
> Anche se le tre variabili /non/ sono oggetti anche per questo mi sembra
> strano che possa venir fuori quella segnalazione specifica.

Lo so. Però il messaggio diceva più o meno così (non vado a cercare la
dizione esatta perché... te lo dico dopo... :-)) lasciandomi un po'
perplesso.

> E , credo di averlo gia' scritto, per come imposti la stringa SQL
> se quella variabile e' nulla al piu' hai un valore /empty/ cioe ''
> nella stringa risultato.
> Hai una option explicit in /tutti/ i moduli?

Yesss!!!

>
>> Se tento di rivalorizzare EserSucc mi appare l'errore chilometrico di
>> runtime di cui ho già scritto "Impossibile assegnare un valore
>> all'oggetto".
>
> Hai verificato la situazione subito prima della chiamata?
> E poi metti un break direttamente sulla entrata della funzione Open e
> riverifica.
>
>> Una precisazione: questa variabile la uso solo in questo modulo, mentre
>
> Ahhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhhh!
> Allora hai mandato in giro notizie false e tendenziose ;-)

Mi prostro e chiedo umilmente perdono :-(

> Da qualche parte fai qualche /stranezza/
>
>> le altre due le uso in tutto il programma e funzionano benissimo.
>> Ora sto riscrivendo tutto il codice per questa maschera e proverò a
>> mettere la variabile solo in locale, speriamo bene! Ciò non toglie però
>> che le... pallottole mi stiano girando vorticosamente...
>>
>>
>>
>
> Perche' non posti lo snip di dove definisci ed inizializzi le variabili?
>

Caro Ale... HO RISOLTO!!!
Onestamente mi vergogno a dirlo perché sono scivolato sulla classica
buccia di banana ed ho commesso un errore che non mi sarei mai aspettato.
La famigerata variabile ha lo stesso nome di un controllo della
frmPreventivi. Controllo che non uso e che ero convinto di aver
cancellato ancora nelle precedenti stesure. Invece, il maledetto si era
nascosto dietro un altro e l'ho scoperto solo per caso accedendo
all'elenco a discesa dei controlli nelle proprietà della form.
Dire che sono rimasto di m.... è usare un eufemismo troppo benevolo.
Sono sinceramente dispiaciuto per il tempo che ti ho fatto perdere.
Grazie comunque per la tua cortesia!

mantro