Un abbonato di Excel Academy ha scritto dei problemi che stava avendo con una macro in esecuzione su un sistema di computer molto potente. Sembra che la macro si blocchi sempre e blocchi la macchina, sempre con un errore di memoria insufficiente. Paolo pensava che se la macro potesse essere eseguita in background, non avrebbe utilizzato così tante risorse e non si sarebbe bloccata.
Molti altri abbonati hanno soppesato questo problema e la maggior parte ha ritenuto che la soluzione in questione non avrebbe necessariamente risolto il problema. Sebbene alcune risorse potrebbero essere rese disponibili, il sistema finirebbe comunque per esaurire la memoria? Perché? Perché i problemi di memoria insufficiente sono in genere dovuti a problemi di codifica nella macro originale. Le “perdite di memoria” (che portano alla condizione di memoria insufficiente) possono essere causate da un numero qualsiasi di problemi nel codice macro.
La soluzione migliore è un giro di debug a tarda notte, scorrere passo-passo il codice macro e analizzare dove si sta insinuando il problema. Cerca prima i problemi più ovvi (ma facilmente trascurati), come i loop infiniti. Se la macro sta eseguendo molte elaborazioni ripetitive (scorrendo i fogli di lavoro), assicurati di rilasciare tutta la memoria dichiarata per la tua macro. Ad esempio, per ogni istruzione SET che usi, dovresti avere un’istruzione corrispondente che imposti l’oggetto su NOTHING, e quelle istruzioni dovrebbero essere all’interno del ciclo.
Se riesci a scorrere le macro senza che falliscano, allora ci sono buone probabilità che la criticità risieda in una sorta di problema di temporizzazione nei thread, un problema di temporizzazione che si presenta, ovviamente, solo quando la macro è in esecuzione “libera”. Se sospetti che questo sia il problema, forse una nuova sequenza degli eventi nella macro può aggirare il problema. Se la macro utilizza DDE, è necessario tenere presente che Microsoft consiglia di utilizzare l’automazione OLE anziché DDE. I problemi di tempistica sono abbastanza comuni con DDE e Microsoft ora lo considera obsoleto e troppo instabile da risolvere (il che significa che non lo supporteranno). In VBA, più chiamate a una subroutine possono anche causare perdite di memoria e tali subroutine devono essere riscritte come funzioni definite dall’utente.
Successivamente, se la macro sta aprendo altre cartelle di lavoro, prova a utilizzare un’istruzione Application.Events = False prima del comando Open. Ciò interrompe l’esecuzione delle macro autoexec nella cartella di lavoro.
Dovresti anche assicurarti che tutti i tuoi riferimenti alle variabili siano completamente dichiarati. Alcuni lettori hanno segnalato di avere un paio di macro che si confondono tra i fogli di lavoro, anche se si utilizza ALT + TAB per rimuovere lo stato attivo da Excel.
Infine, un abbonato ha riferito di aver trovato VBA di Excel un po’ “sensibile” (per mancanza di una parola migliore). Le macro funzionerebbero per un po’, verrebbero modificate e quindi fallirebbero continuamente. L’unica soluzione trovata da questo abbonato è stata esportare tutto il codice in un file di testo, eliminare tutto il codice dal modello e quindi ripristinarlo. Strano? Sì, ma è difficile discutere con il successo ;).
