Check In
copia linkComando di check-in
L'operazione di check-in permette di inviare al server le modifiche eseguite sul progetto e presenti nella copia client. Tale operazione può essere effettuata sia su uno o più oggetti dell'albero (videata, procedura, folder, etc.) sia dalla videata dei lock.
Instant Developer, a prescindere dal modo in cui viene effettuato il check-in, calcola una lista di lock di cui è necessario fare il check-in. Se il comando viene avviato dalla lista dei lock Instant Developer effettua il check-in di tutti i lock selezionati. Se si effettua il check-in a partire da uno o più oggetti del progetto, Instant Developer prepara una lista di tutti i lock che riguardano gli oggetti selezionati o uno qualsiasi dei loro figli. Al termine di questa procedura il client possiede un elenco di lock di cui occorre fare il check-in.
Da questo elenco il client elimina tutti i lock che riguardano oggetti inseriti e poi cancellati. Tali oggetti, infatti, non sono conosciuti dal server.
A questo punto il client cerca di aggiungere all'elenco tutti gli altri lock che sono stati presi all'interno della stessa modifica. Per fare un esempio quando viene modificato un campo del database, viene preso un lock su ogni procedura che contenga riferimenti a quel campo nonché ogni videata che contenga pannelli che si riferiscano a quel campo. Se poi si effettua il check-in del campo del database, Instant Developer, per coerenza, effettua il check-in anche delle modifiche riguardanti le procedure e le videate modificate in conseguenza della modifica al campo anche se il check-in è stato fatto a partire dal menu contestuale del database. Questo algoritmo non prende in considerazione né i lock di tipo Offline, che rimangono Offline, né i lock di tipo Temporaneo che, per l'appunto, riguardano solo il client e solo a lui sono noti.
Una volta che la lista dei lock è pronta il client prepara un progetto speciale chiamato Progetto Parziale. Tale progetto contiene per intero tutti gli oggetti corrispondenti ai lock di cui si sta effettuando il check-in. Inoltre tutti gli oggetti da essi referenziati. Questi ultimi possono essere presenti anche in forma parziale dato che servono solo per far sì che gli oggetti di cui si sta facendo il check-in siano completi. Il progetto parziale, poi, contiene tutti i padri di ogni oggetto affinché il progetto parziale abbia la stessa struttura del progetto originale. Infine il progetto parziale contiene la lista dei lock di cui vogliamo fare il check-in.
Per fare un semplice esempio il check-in della seguente procedura:
Esempio di procedura di cui è stato effettuato il check-in.
causa l'invio al server del seguente progetto parziale:
Progetto parziale inviato al server a seguito del check-in della procedura.
Come si vede il progetto contiene l'intera procedura (è l'oggetto convolto dal check-in ed occorre che questo sia completo), nonché le due costanti usate nella procedura e l'operatore + (anch'esso usato nella procedura). Infine contiene, come descritto sopra, i padri degli oggetti (videata, applicazione web, libreria client, lista valori General Constants, ...) necessari a contenere gli oggetti convolti nel check-in.
Il server riceve il progetto parziale che, a sua volta, contiene la lista dei lock di cui occorre fare il check-in e apre la copia master per apportare le modifiche richieste. Poi per ogni lock presente nel progetto parziale la cui operazione non sia Eliminato simula un'operazione di Drag&Drop tirando ogni oggetto collegato ai lock dal progetto parziale alla copia master. Tale operazione importa e/o aggiorna gli oggetti sulla copia master. Se il lock è di tipo Eliminato l'oggetto verrà eliminato dalla copia master.
L'operazione di check-in termina quando tutti i lock sono stati gestiti. Una volta completate le operazioni di Drag&Drop il server verifica che tutti gli oggetti convolti nel check-in siano stati copiati al posto giusto, verificando se si trovano all'interno dello stesso padre indicato nel progetto parziale. Qualora il lock di cui viene fatto il check-in possegga il flag Riordinato il progetto parziale contiene anche l'oggetto seguente a quello di cui si sta facendo il check-in, per permettere al server di posizionare l'oggetto al posto giusto.
Al termine dell'operazione di check-in, il server aumenta di una unità il numero di versione di ogni oggetto convolto dalla modifica. Tornando all'esempio precedente, al termine della procedura di check-in, la versione della procedura viene incrementata di una unità. Se le costanti esistevano già sulla copia master, l'operazione di Drag&Drop non le coinvolge quindi la loro versione non cambia. Se le costanti non esistevano già queste vengono importate nella copia master e la loro versione incrementata. Il server, quindi, invia al client tutte le versioni degli oggetti cambiati durante l'operazione di check-in così che queste vengano aggiornate anche nella copia locale. Tale numero di versione viene utilizzato durante la procedura di verifica effettuata durante il check-out già descritta nell'articolo relativo.
Durante la procedura di check-in avvengono anche alcune operazioni sul database. In particolare:
- Prima di avviare il check-in il sistema crea un nuovo record nella tabella del database che descrive l'operazione di check-in. Tale record contiene i dettagli dell'oggetto di cui si fa il check-in, i dati riguardanti l'utente che ha effettuato il check-in, la data/ora dell'operazione e le eventuali note digitate dall'utente nell'apposita videata di check-in. Nello stesso record viene caricata la copia master prima che l'operazione di check-in abbia inizio ed il progetto parziale utilizzato.
Videata mostrata all'utente quando viene avviata un'operazione di check-in sul client.
Si è verificato un errore durante l'inserimento di un nuovo record nella tabella Check In. Qualora l'errore riguardi il database il messaggio di errore è seguito dal testo dell'errore così come viene generato dal driver utilizzato per accedere al database. Qualora l'errore del driver non sia presente o le informazioni comunicate dal driver non siano sufficienti a risolvere il problema, occorre contattare l'assistenza.
Il messaggio indica che non è stato possibile caricare la nuova copia master sul database. Se l'errore è dovuto al database il messaggio di errore è seguito dal testo dell'errore così come viene generato dal driver utilizzato per accedere al database. Qualora l'errore del driver non sia presente o le informazioni comunicate dal driver non siano sufficienti a risolvere il problema, occorre contattare l'assistenza.
Il messaggio indica che non è stato possibile caricare la vecchia copia master nel record riguardante il check-in. Se l'errore è dovuto al database il messaggio di errore è seguito dal testo dell'errore così come viene generato dal driver utilizzato per accedere al database. Qualora l'errore del driver non sia presente o le informazioni comunicate dal driver non siano sufficienti a risolvere il problema, occorre contattare l'assistenza.
Tale errore informa che il check-in non ha avuto alcun effetto sulla copia master. Qualora questo non sia il risultato atteso è necessario contattare l'assistenza.
Tale errore informa che le modifiche sono state interrotte dal server di Team Works e la copia master non è stata modificata. Tutti gli errori che hanno causato l'interruzione dell'operazione di check-in vengono recuperati dal client e mostrati nella videata dei messaggi del client. Occorre leggere il testo degli errori per capire qual'è la causa dell'interruzione.
Il messaggio indica che non è stato possibile caricare il progetto parziale nel record riguardante il check-in. Se l'errore è dovuto al database il messaggio di errore è seguito dal testo dell'errore così come viene generato dal driver utilizzato per accedere al database. Qualora l'errore del driver non sia presente o le informazioni comunicate dal driver non siano sufficienti a risolvere il problema, occorre contattare l'assistenza.
Durante l'operazione di importazione ed eliminazione degli oggetti sulla copia master potrebbero presentarsi delle situazioni inattese: ad esempio, il server potrebbe non trovare un oggetto durante la gestione di un lock di spostamento. In questo caso il server prosegue comunque l'operazione di check-in cercando di portarla a termine. Alla fine della procedura il server invia al client tutti gli errori generati durante l'operazione. Questi messaggi vengono mostrati nella videata dei messaggi del client. Di seguito sono elencati i possibili messaggi generati dal server durante l'esecuzione dell'operazione di check-in:
Questo messaggio ci informa che il server ha ricevuto un lock di tipo Riordinato e che quindi deve spostare l'oggetto. Ma l'oggetto non è presente nella copia master quindi lo spostamento non è avvenuto.
Questo messaggio ci informa che il server ha ricevuto un lock di tipo Spostato e che quindi deve spostare l'oggetto all'interno di un nuovo padre. Ma l'oggetto non è presente nella copia master quindi il riparentamento non è avvenuto.
Questo messaggio ci informa che il server ha ricevuto un lock di tipo Sspostato e che quindi deve spostare l'oggetto all'interno di un nuovo padre. Ma il nuovo oggetto padre (%2) non è presente nella copia master quindi il riparentamento non è avvenuto.
Questo messaggio ci informa che il server stava gestendo un lock di tipo oggetto la cui esecuzione prevedeva di recuperare l'oggetto e copiarne le proprietà estraendole dallo stesso oggetto contenuto nel progetto parziale. Tale oggetto, però, non è stato trovato nella copia master e non è quindi stato possibile aggiornarlo come richiesto.
Queste segnalazioni non rappresentano di per sè un errore, ma solo una situazione inattesa. In questi casi si consiglia di controllare le differenze fra la copia master e la copia locale per vedere se è tutto a posto.
Ultima modifica: 23/03/2021 / Validità: da 7.5.3400