Come utilizzare Primavera P6 Professional 25.12 da casa, in ufficio e in cantiere, mantenendo un database principale Oracle e la possibilità di lavorare senza Internet.
Introduzione
Nei precedenti articoli abbiamo visto come installare Primavera P6 Professional 25.12 su Oracle Database 21c Express Edition, configurare il database applicativo e realizzare un sistema di backup automatico.
Una volta completata l’infrastruttura, mi sono trovato di fronte a una nuova esigenza, piuttosto comune per chi lavora nel project planning e nel controllo dei grandi progetti infrastrutturali.
Come utilizzare Primavera P6 da più computer, anche quando ci si trova presso un cliente o in un cantiere dove non è disponibile una connessione Internet affidabile?
La soluzione che ho adottato combina tre tecnologie:
- Oracle Database 21c XE, installato sul computer principale;
- WireGuard, per accedere al database da remoto;
- SQLite, già disponibile sul notebook, per lavorare temporaneamente offline.
L’idea è semplice: conservare tutti i progetti nel database Oracle principale e trasferire sul notebook soltanto quelli sui quali devo lavorare quando non posso collegarmi alla rete.
In questo articolo descriverò l’architettura, la configurazione della VPN e la procedura operativa per trasferire un progetto fra Oracle e SQLite attraverso i file XER di Primavera.
È importante precisare che il collegamento remoto a Oracle è stato effettivamente configurato e verificato, mentre il flusso completo di trasferimento offline tramite XER costituisce la procedura operativa da collaudare prima dell’utilizzo su progetti reali.
1. Il problema: lavorare con P6 da più postazioni
Nella mia attività professionale utilizzo Primavera P6 per programmare e controllare i lavori di grandi infrastrutture.
Lavorare su un solo computer non è sempre pratico.
A casa dispongo di una postazione desktop, sulla quale posso gestire comodamente i programmi lavori, effettuare analisi e conservare i diversi progetti.
Quando mi sposto presso i clienti utilizzo invece un notebook.
La prima soluzione potrebbe essere installare Primavera P6 su entrambi i computer e mantenere due database separati.
Questo approccio, tuttavia, presenta diversi inconvenienti:
- duplicazione degli archivi progettuali;
- difficoltà nel mantenere aggiornate le due copie;
- rischio di modificare versioni differenti dello stesso progetto;
- maggiori difficoltà nella gestione dei backup;
- assenza di un archivio centrale di riferimento.
Ho quindi preferito adottare un database Oracle unico, raggiungibile dalle diverse installazioni Primavera.
Rimane però il problema della connettività: quando non è possibile collegarsi a casa, il notebook deve poter continuare a lavorare.
2. Architettura della soluzione
La configurazione prevede due computer con ruoli distinti.
Computer principale: il database centrale
Sul desktop Windows 11 sono installati:
- Oracle Database 21c Express Edition;
- Primavera P6 Professional 25.12;
- WireGuard;
- il sistema di backup automatico.
Il database Oracle contiene l’insieme dei progetti.
È l’archivio principale, utilizzato normalmente per la gestione e la conservazione delle informazioni di pianificazione.
Notebook: postazione mobile
Sul notebook è installato Primavera P6 Professional.
Sono disponibili due connessioni database:
Oracle remoto, da utilizzare quando il notebook può raggiungere il computer principale attraverso la rete locale oppure la VPN.
SQLite locale, da utilizzare quando non è disponibile la connessione Internet.
In quest’ultimo ambiente vengono conservati soltanto i progetti necessari per l’attività offline.
Non è quindi necessario installare un secondo server Oracle sul notebook.
Schema dell’architettura
INTERNET
|
Router TIM
|
VPN WireGuard
|
+--------------------------+
| PC PRINCIPALE - WINDOWS 11|
| |
| Primavera P6 |
| Oracle Database 21c XE |
| XEPDB1 |
| Tutti i progetti |
| Backup automatici |
+--------------------------+
|
VPN / Rete LAN
|
+--------------------------+
| NOTEBOOK |
| |
| Primavera P6 |
| Connessione Oracle |
| Database SQLite locale |
| Solo progetti offline |
+--------------------------+
Il sistema consente quindi due modalità operative:
| Situazione | Database utilizzato |
|---|---|
| Lavoro dal desktop di casa | Oracle XE |
| Notebook collegato alla LAN | Oracle XE |
| Notebook collegato tramite VPN | Oracle XE |
| Notebook senza Internet | SQLite locale |
In presenza di una connessione funzionante, il notebook utilizza direttamente il database principale.
In assenza di connettività, il lavoro prosegue sulla copia locale del progetto preventivamente trasferita.
3. Configurazione del database Oracle centrale
Nel mio ambiente Oracle utilizza i seguenti parametri:
| Parametro | Valore |
|---|---|
| Database | Oracle 21c XE |
| Oracle SID | XE |
| Pluggable Database | XEPDB1 |
| Porta listener | 1521 |
| Schema principale P6 | ADMUSER |
La connessione locale dal computer principale è:
localhost:1521/XEPDB1Per verificare che Oracle sia attivo possiamo utilizzare SQL*Plus:
sqlplus / as sysdbaQuindi:
SHOW PDBS;Il pluggable database XEPDB1 deve risultare aperto.
Per verificare il listener:
lsnrctl statusFra i servizi registrati deve comparire XEPDB1.
Il listener è il componente che riceve le connessioni dei client Oracle.
La sua porta, nella configurazione adottata, è TCP 1521.
È importante ricordare che la porta 1521 non deve essere pubblicata direttamente su Internet.
Per l’accesso da remoto utilizzeremo esclusivamente la VPN.
4. Perché utilizzare WireGuard?
Per raggiungere Oracle da fuori casa occorre creare un collegamento sicuro fra notebook e rete domestica.
Ho scelto WireGuard, una VPN che utilizza crittografia moderna e una configurazione relativamente semplice.
WireGuard permette di assegnare indirizzi IP virtuali ai computer collegati, indipendentemente dalla rete fisica utilizzata.
Nella configurazione realizzata ho utilizzato:
| Dispositivo | Indirizzo WireGuard |
|---|---|
| PC principale | 10.10.10.1 |
| Notebook | 10.10.10.2 |
Quando il tunnel VPN è attivo, il notebook può raggiungere il computer principale attraverso l’indirizzo:
10.10.10.1Questo indirizzo rimane costante anche se cambia l’indirizzo IP pubblico della connessione domestica.
L’indirizzo WireGuard rappresenta infatti il computer all’interno della rete privata virtuale.
5. Configurazione del server WireGuard
Sul computer principale viene configurata un’interfaccia WireGuard con indirizzo:
Address = 10.10.10.1/24La porta UDP utilizzata dal server deve essere scelta e configurata coerentemente con le regole del router e del firewall.
Un esempio è:
ListenPort = 51820Ogni dispositivo WireGuard possiede una coppia di chiavi crittografiche, pubblica e privata.
La chiave privata non deve essere condivisa.
Il server riconosce il notebook mediante la sua chiave pubblica e gli assegna l’indirizzo consentito:
AllowedIPs = 10.10.10.2/32Questi parametri rappresentano soltanto le impostazioni essenziali, non un file di configurazione completo.
Sul computer principale bisogna inoltre verificare che il firewall Windows consenta le comunicazioni VPN necessarie e che Oracle sia raggiungibile dall’interfaccia prevista.
La rete VPN deve permettere al notebook di raggiungere la porta TCP 1521 del database, ma non deve necessariamente consentire l’accesso indiscriminato a tutti i servizi Windows.
Configurazione del router
Sul router domestico è necessario inoltrare la porta UDP utilizzata da WireGuard verso l’indirizzo LAN del computer che esegue il server VPN.
È un dettaglio importante: il port forwarding non deve puntare all’indirizzo virtuale 10.10.10.1, ma all’indirizzo fisico del server sulla rete domestica, ad esempio 192.168.1.10.
Conviene assegnare al desktop una prenotazione DHCP, in modo che il suo indirizzo LAN rimanga costante.
Il collegamento dall’esterno richiede inoltre che la connessione Internet disponga di un indirizzo pubblico raggiungibile oppure di una soluzione alternativa capace di superare eventuali limitazioni CGNAT.
6. Come gestire l’indirizzo IP pubblico dinamico
La connessione Internet domestica non dispone necessariamente di un indirizzo IP pubblico statico.
Questo significa che il provider può cambiarlo periodicamente.
Se il notebook utilizza direttamente l’indirizzo pubblico numerico, il collegamento WireGuard potrebbe smettere di funzionare dopo un cambiamento.
La soluzione consiste nell’utilizzare un servizio Dynamic DNS, abbreviato DDNS.
Il DDNS permette di associare un nome Internet all’indirizzo IP pubblico corrente.
Un esempio è:
p6vpn.duckdns.orgQuesto nome è puramente illustrativo.
DuckDNS attraverso il router TIM
Il router TIM Technicolor utilizzato nella mia rete dispone di una sezione per la configurazione dei servizi Dynamic DNS, fra i quali DuckDNS.
È una soluzione particolarmente comoda perché il router può occuparsi direttamente dell’aggiornamento dell’indirizzo pubblico.
Il procedimento generale è:
- Creare un account presso DuckDNS.
- Registrare un hostname.
- Configurare il provider DDNS nel router.
- Inserire le credenziali o il token richiesto.
- Verificare che il nome DNS risolva nell’indirizzo pubblico corretto.
La configurazione precisa dipende dal firmware del router.
Un servizio DDNS non sostituisce il port forwarding e non risolve da solo un’eventuale situazione di CGNAT.
Modifica del notebook WireGuard
Nel client WireGuard, invece di utilizzare un indirizzo pubblico numerico, possiamo specificare:
Endpoint = p6vpn.duckdns.org:51820Dove l’hostname è quello effettivamente registrato e la porta è quella configurata sul server.
Quando l’indirizzo pubblico cambia, il servizio DDNS aggiorna il relativo record DNS.
WireGuard utilizzerà il nome configurato per individuare il server, anche se in determinate condizioni potrebbe essere necessario riattivare il tunnel affinché venga risolto nuovamente l’hostname aggiornato.
7. Verificare il collegamento VPN
Una volta configurata la VPN, possiamo effettuare un primo test.
Dal notebook, con WireGuard attivo:
ping 10.10.10.1Se il firewall consente le richieste ICMP, il computer principale dovrebbe rispondere.
Un ping senza risposta, tuttavia, non dimostra necessariamente che il tunnel non funzioni: il protocollo ICMP potrebbe essere bloccato.
Per verificare direttamente la porta Oracle possiamo utilizzare PowerShell:
Test-NetConnection 10.10.10.1 -Port 1521Il risultato dovrebbe indicare:
TcpTestSucceeded : TrueSuccessivamente eseguiamo una vera connessione al database:
sqlplus admuser@//10.10.10.1:1521/XEPDB1Inseriamo la password richiesta.
Se SQL*Plus si collega correttamente, il notebook è in grado di raggiungere Oracle attraverso WireGuard.
Nel mio ambiente questo collegamento è stato verificato con successo.
Ho quindi configurato Primavera P6 Professional per utilizzare la stessa connessione.
8. Configurare Primavera P6 sul notebook
Primavera P6 Professional può utilizzare diverse configurazioni di connessione.
Nel notebook ho già disponibile un database SQLite locale e ho predisposto anche l’accesso al database Oracle centrale.
Le due connessioni devono essere chiaramente riconoscibili.
Suggerisco denominazioni come:
P6 - ORACLE CASA
P6 - SQLITE OFFLINESono semplicemente nomi descrittivi degli alias P6.
Connessione Oracle
I parametri della connessione remota sono:
Host: 10.10.10.1
Porta: 1521
Servizio: XEPDB1La VPN deve essere attiva prima dell’avvio della connessione al database remoto.
Quando il notebook si trova sulla rete locale è possibile utilizzare anche l’indirizzo LAN del desktop, se la configurazione di rete lo consente.
Connessione SQLite
SQLite è un database locale che non richiede l’esecuzione di un server Oracle.
Il vantaggio è evidente: i dati restano disponibili sul notebook anche quando la rete è completamente assente.
Questo lo rende interessante per l’utilizzo in cantiere, durante trasferte o presso clienti con connettività limitata.
Il database SQLite, tuttavia, è indipendente da quello Oracle.
Le modifiche apportate a uno dei due archivi non vengono trasferite automaticamente all’altro.
9. Come trasferire un progetto da Oracle a SQLite
Per lavorare offline è necessario trasferire preventivamente il progetto nel database SQLite del notebook.
Primavera P6 mette a disposizione il formato XER, utilizzato per lo scambio di progetti.
L’estensione del file è:
.xerIl formato contiene una rappresentazione strutturata di numerosi dati del progetto, comprese attività, WBS, relazioni e altre informazioni di pianificazione.
Non si tratta, però, di una replica completa del database.
Esportazione dal database Oracle
Con Primavera collegato a Oracle:
- Apriamo il progetto da trasferire.
- Selezioniamo File → Export.
- Scegliamo il formato Primavera PM XER.
- Selezioniamo soltanto il progetto interessato.
- Salviamo il file nella cartella di scambio.
Un nome possibile è:
PROGETTO_A_2026-10-21_ORACLE.xerImportazione nel database SQLite
Successivamente:
- Chiudiamo Primavera o usciamo dalla sessione Oracle.
- Avviamo P6 selezionando il database SQLite locale.
- Apriamo File → Import.
- Scegliamo il formato XER.
- Selezioniamo il file esportato.
- Importiamo il progetto nell’EPS locale.
- Verifichiamo che le informazioni siano state trasferite correttamente.
Questa operazione richiede una particolare attenzione quando nel database locale esistono già progetti con lo stesso identificativo.
È necessario scegliere consapevolmente se creare un progetto nuovo oppure aggiornare quello esistente.
Prima del primo utilizzo operativo è consigliabile effettuare la procedura su un progetto di prova.
10. Lavorare offline presso il cliente
Una volta trasferito il progetto nel database SQLite, possiamo lavorare senza alcuna connessione al computer principale.
Per esempio, durante una giornata in cantiere possiamo:
- aggiornare le attività;
- registrare gli avanzamenti;
- modificare durate e date;
- correggere le relazioni logiche;
- aggiornare il programma lavori;
- eseguire il calcolo della schedulazione;
- analizzare eventuali slittamenti e criticità.
Tutte le modifiche vengono salvate nel database locale.
Nel frattempo, però, il progetto originale rimane presente anche nel database Oracle.
È qui che entra in gioco la regola operativa più importante:
Quando un progetto viene trasferito sul notebook per una sessione di lavoro offline, la copia su Oracle deve essere considerata temporaneamente non modificabile.
Non si tratta di un blocco automatico imposto dal database.
È una regola organizzativa che deve essere rispettata da tutti gli eventuali utilizzatori.
Se qualcuno continuasse a modificare contemporaneamente il progetto Oracle, al ritorno del notebook avremmo due versioni divergenti.
Il formato XER non fornisce un meccanismo automatico di risoluzione dei conflitti paragonabile a quello dei sistemi di controllo versione del software.
11. Riportare il progetto aggiornato su Oracle
Terminata la giornata di lavoro, il progetto locale deve essere riportato nel database centrale.
Esportazione dal notebook
Apriamo Primavera utilizzando SQLite e selezioniamo il progetto aggiornato.
Esportiamo il progetto in formato XER, utilizzando un nome differente dal file originale:
PROGETTO_A_2026-10-21_1800_OFFLINE.xerIl nome comprende data, ora e origine del file.
In questo modo possiamo distinguere facilmente il progetto prelevato da Oracle da quello modificato sul notebook.
Importazione nel database Oracle
Riattiviamo la VPN e apriamo Primavera attraverso la connessione Oracle.
Prima di importare il file, è opportuno salvare una copia di sicurezza dello stato attuale del progetto centrale.
Successivamente:
- Apriamo File → Import.
- Selezioniamo il formato XER.
- Indichiamo il file aggiornato.
- Selezioniamo l’azione di importazione appropriata.
- Verifichiamo che il progetto di destinazione sia quello corretto.
- Controlliamo attentamente le opzioni relative all’aggiornamento dei dati.
- Completiamo l’importazione.
- Verifichiamo il progetto risultante.
L’aggiornamento di un progetto esistente non deve essere interpretato come una semplice sovrascrittura integrale e indiscriminata.
Le opzioni del wizard possono influenzare il comportamento dei dati già presenti, delle attività aggiunte, delle risorse, dei codici e delle altre informazioni.
In particolare, non bisogna presumere che l’aggiornamento elimini automaticamente ogni oggetto rimosso dalla copia offline.
Il risultato va sempre controllato.
12. XER e XML: quale formato scegliere?
Primavera P6 supporta diversi formati di scambio.
Fra i più utilizzati vi sono XER e Primavera XML.
| Caratteristica | XER | Primavera XML |
|---|---|---|
| Scambio di progetti P6 | Sì | Sì |
| Utilizzo in ambito planning | Molto diffuso | Diffuso |
| Trasferimento attività e relazioni | Sì | Sì |
| Gestione di alcuni dati avanzati | Con limitazioni | Dipende dal tipo di dato |
| Baseline e riferimenti progettuali | Richiede verifiche | Generalmente più flessibile |
| Semplicità di scambio | Elevata | Buona |
Il formato XER è particolarmente comune negli scambi contrattuali e nella trasmissione dei programmi lavori.
Il formato XML può risultare preferibile per determinate informazioni che non vengono rappresentate completamente in XER.
La scelta dipende dalle caratteristiche del progetto e dalle informazioni che si desidera conservare.
Per il trasferimento operativo fra i due database intendo iniziare con XER, verificando però su un progetto di prova che tutti gli elementi necessari siano effettivamente mantenuti.
13. Cosa controllare dopo ogni trasferimento
Non è sufficiente verificare che Primavera riesca ad aprire il progetto.
Dopo l’importazione occorre controllare la corrispondenza dei dati.
Gli elementi principali sono:
| Elemento | Verifica |
|---|---|
| Project ID | Identificativo corretto |
| WBS | Struttura invariata |
| Attività | Numero e codici coerenti |
| Relazioni | Predecessori e successori |
| Calendari | Assegnazioni corrette |
| Date | Inizio, fine e data di stato |
| Avanzamenti | Percentuali e durate residue |
| Risorse | Assegnazioni e disponibilità |
| Costi | Valori e distribuzione |
| Baseline | Presenza e associazione |
| UDF e codifiche | Valori trasferiti |
Suggerisco inoltre di effettuare il calcolo della schedulazione, mantenendo coerenti la data di stato e le impostazioni di scheduling.
È opportuno confrontare i risultati prima e dopo il trasferimento.
Se il progetto utilizza numerosi calendari globali, risorse condivise o campi personalizzati, il processo deve essere collaudato con particolare attenzione.
Questi elementi possono dipendere anche dalla configurazione del database di destinazione.
14. Organizzare una cartella di scambio XER
Per evitare di confondere le versioni ho previsto una struttura di cartelle dedicata.
Un esempio è:
P6_Exchange
│
├── DA_ORACLE
│
├── DA_SQLITE
│
├── IMPORTATI
│
└── ARCHIVIOLa cartella DA_ORACLE contiene i progetti esportati dal database centrale e destinati al notebook.
DA_SQLITE contiene i progetti aggiornati offline e pronti per essere trasferiti su Oracle.
IMPORTATI raccoglie i file che hanno completato il processo di importazione e verifica.
ARCHIVIO conserva le versioni storiche.
Queste cartelle possono essere collocate in una directory sincronizzata con Google Drive, purché sia configurata sui computer coinvolti.
La sincronizzazione cloud può aiutare a trasferire fisicamente i file XER da una postazione all’altra.
Non deve però essere confusa con una sincronizzazione dei database Primavera.
Google Drive trasferisce i file; non interpreta le modifiche ai progetti e non risolve i conflitti fra Oracle e SQLite.
È inoltre necessario verificare che il file sia completamente sincronizzato prima di importarlo e che il notebook disponga di una copia locale utilizzabile offline.
15. Una semplice procedura di check-out e check-in
Per rendere il sistema più affidabile possiamo adottare un procedimento simile al check-out e check-in utilizzato in altri sistemi informatici.
Check-out: il progetto esce da Oracle
Quando devo lavorare offline:
- Verifico che nessun altro stia modificando il progetto.
- Esporto una copia XER aggiornata.
- Importo il progetto nel notebook.
- Verifico l’importazione.
- Segno il progetto come temporaneamente assegnato al lavoro offline.
Check-in: il progetto ritorna su Oracle
Quando termino il lavoro:
- Esporto la versione aggiornata da SQLite.
- Conservo il file XER originale come riferimento.
- Eseguo una copia di sicurezza del progetto Oracle.
- Importo la versione aggiornata in Oracle.
- Controllo le differenze e la consistenza dei dati.
- Verifico il risultato della schedulazione.
- Confermo la conclusione del trasferimento.
Da questo momento Oracle torna a essere l’archivio principale aggiornato.
Questo processo non è automatico, ma ha il vantaggio di essere semplice da comprendere, documentare e controllare.
Nel mio caso, lavorando generalmente su un solo progetto alla volta quando sono presso il cliente, è una soluzione particolarmente adatta.
16. Perché non sincronizzare direttamente Oracle e SQLite?
Una domanda naturale è se sia possibile mantenere i due database costantemente sincronizzati.
In teoria esistono tecnologie di replica e sincronizzazione dei dati, ma applicarle a Primavera P6 non è così semplice.
Oracle XE e SQLite utilizzano strutture e meccanismi differenti.
Inoltre, il database Primavera contiene numerose relazioni fra tabelle, identificativi interni e informazioni applicative che non possono essere sincronizzate semplicemente copiando i record modificati.
Una replica bidirezionale non supportata potrebbe creare problemi di integrità e rendere inutilizzabile il database.
Per questo motivo ho escluso l’idea di un cluster fra Oracle sul desktop e SQLite sul notebook.
La soluzione che preferisco è:
Oracle come database principale, SQLite come ambiente temporaneo offline e XER come strumento di trasferimento controllato dei singoli progetti.
Il trasferimento non è in tempo reale, ma evita di introdurre una complessità infrastrutturale sproporzionata rispetto all’esigenza.
17. Sicurezza e continuità operativa
Questa architettura permette di separare tre aspetti fondamentali.
Disponibilità
Quando Internet funziona, il notebook accede al database centrale attraverso WireGuard.
Quando Internet non funziona, è possibile continuare a lavorare sul progetto già trasferito localmente.
Sicurezza
La porta Oracle non viene esposta direttamente a Internet.
Il collegamento remoto avviene attraverso un tunnel VPN cifrato, con chiavi distinte per i dispositivi.
È comunque necessario proteggere gli account Oracle, le credenziali di Primavera e le chiavi WireGuard.
Protezione dei dati
Il desktop conserva l’archivio principale e viene sottoposto alle procedure di backup descritte nel precedente articolo.
Durante il lavoro offline, però, le modifiche più recenti esistono soltanto nel database SQLite del notebook, fino al successivo trasferimento su Oracle.
Per questo motivo occorre predisporre anche una strategia di backup del database locale del notebook, evitando di copiare i file mentre il database è in uso se la procedura non garantisce una copia consistente.
I file XER esportati al termine della sessione rappresentano una protezione aggiuntiva del singolo progetto, ma non sostituiscono un backup completo e coerente dell’ambiente SQLite.
18. Vantaggi e limiti della soluzione
L’architettura descritta presenta diversi vantaggi:
- un unico database principale;
- accesso ai progetti da più postazioni;
- connessione remota cifrata;
- nessuna seconda installazione Oracle sul notebook;
- possibilità di lavorare senza Internet;
- trasferimento dei singoli progetti tramite un formato diffuso;
- gestione relativamente semplice dell’infrastruttura.
Esistono tuttavia anche alcuni limiti.
Il computer principale deve rimanere acceso e raggiungibile per consentire le connessioni remote.
La VPN dipende dalla disponibilità della connessione domestica e da quella del notebook.
Il lavoro offline richiede una preparazione preventiva.
Il trasferimento XER deve essere verificato e non garantisce una replica completa di tutti i dati globali o di ogni configurazione del progetto.
Infine, il controllo delle versioni richiede disciplina: bisogna evitare che lo stesso progetto venga modificato contemporaneamente nei due ambienti.
Conclusioni
Realizzare un ambiente Primavera P6 utilizzabile da più computer non richiede necessariamente un’infrastruttura server complessa.
Nel mio caso ho scelto di combinare un database Oracle 21c XE centralizzato, una VPN WireGuard e il database SQLite già disponibile sul notebook.
La configurazione consente di utilizzare normalmente tutti i progetti conservati sul computer principale e, quando necessario, di portare offline soltanto quello sul quale devo lavorare.
Il punto fondamentale non è cercare di sincronizzare continuamente due database differenti, ma organizzare correttamente il flusso dei dati.
La procedura basata su esportazione, importazione e verifica dei file XER permette di mantenere il controllo delle versioni senza introdurre meccanismi di replica non supportati.
Per un planner che lavora fra casa, uffici tecnici e cantieri, il vero vantaggio è poter accedere a un ambiente centralizzato senza rinunciare alla possibilità di continuare a lavorare quando la connessione Internet non è disponibile.
Il prossimo passo sarà collaudare sistematicamente il trasferimento di un progetto reale fra Oracle e SQLite, verificando attività, calendari, relazioni, risorse, avanzamenti e baseline.
Solo dopo questa verifica sarà possibile consolidare il processo come procedura ordinaria di lavoro.
Articolo basato su un’infrastruttura reale con Primavera P6 Professional 25.12, Oracle Database 21c XE, Windows 11 e WireGuard. L’accesso Oracle tramite VPN è stato verificato; il ciclo di lavoro offline e reimportazione XER è descritto come procedura proposta da sottoporre a collaudo prima dell’utilizzo in produzione.
