Check Out
copia linkComando di Check Out
L'operazione di check-out consiste nel richiedere al server l'autorizzazione ad apportare modifiche ad un oggetto o al suo contenuto. Ogni lock fornito dal server è conservato sia sul server che sul client così che quest'ultimo non sia obbligato a chiedere nuove autorizzazioni ogni volta che lo stesso oggetto viene modificato. I lock vengono automaticamente eliminati da Instant Developer sia dopo un'operazione di Check In, sia dopo un'operazione di Get Latest.
Vediamo ora quali tipi di lock sono gestiti da Team Works:
- lock di tipo oggetto: questo tipo di lock autorizza il client a modificare solamente l'oggetto (nome, descrizione, etc.);
- lock di tipo contenuto: questo tipo di lock autorizza il client a modificare l'oggetto e uno qualsiasi dei suoi oggetti figli. Per esempio un lock di tipo contenuto su una videata permette di modificare tutto ciò che è contenuto nella videata (procedure, pannelli, campi di pannello, query, procedure, eventi, ...) mentre un lock di tipo oggetto sulla videata permette di modificare le sole proprietà della videata;
- lock di tipo interfaccia: riguarda l'autorizzazione alla modifica all'interfaccia di un oggetto. Per esempio, se viene aggiunto un parametro ad una procedura, verrà preso un lock di interfaccia sulla procedura ed uno o più lock sulle procedure che contengono chiamate alla procedura modificata.
Ogni lock, inoltre, possiede altre proprietà, quali:
- Riordinato: indica che l'oggetto ha cambiato posizione pur conservando l'oggetto padre (per esempio una costante spostata all'interno della stessa lista valori);
- Spostato: indica che l'oggetto ha cambiato padre;
- Offline: il lock è stato preso quando Instant Developer client era in modalità disconnessa. Questo lock verrà automaticamente convertito in Online non appena viene effettuato il login sul server.
- Temporaneo: il lock viene preso solo sul client senza contattare il server. Questo tipo di lock viene normalmente utilizzato se si vuole modificare un oggetto senza bloccare il lavoro di altri programmatori. Normalmente può essere utile un lock temporaneo di tipo oggetto sull'oggetto database se si desidera cambiare i parametri di connessione durante lo sviluppo dell'applicazione. In questo modo il lock è conservato solo sul client mentre l'oggeto database rimane libero per eventuali altre modifiche effettuate dagli altri programmatori.
Da ultimo, ogni lock, ricorda la prima operazione che ne ha causato la generazione:
- Inserito: riguarda un oggetto che è stato inserito e che, quindi, non è ancora presente nella copia master;
- Modificato: riguarda una modifica ad un oggetto già esistente sulla copia master;
- Eliminato: riguarda la cancellazione di un oggetto che, quindi, è ancora presente nella copia master ma non è più presente nella copia locale.
Durante la modifica del progetto è Instant Developer che si occupa di richiedere al server i lock necessari; non è quindi necessaria una operazione di check-out manuale. Se siamo in modalità offline viene presentata all'utente una videata che richiede cosa fare:
Videata mostrata quando si tenta di prendere un lock mentre si è in modalità disconnessa.
Tramite questa videata possiamo prendere un lock di tipo offline, prendere un lock temporaneo o annullare la modifica. Se si decide di effettuare la modifica è importante notare che stiamo deviando dalla linea di sviluppo con possibili problemi di risincronizzazione quando torniamo online.
Durante l'esecuzione della procedura di check-out, il server viene automaticamente contattato chiedendo se è possibile effettuare la modifica all'oggetto: il client invia, oltre alle informazioni riguardanti l'oggetto di cui si vuole il lock, anche alcune informazioni accessorie, dipendenti dal tipo di lock. In particolare se il lock è di tipo contenuto o interfaccia viene inviato l'elenco delle versioni di tutti gli oggetti figli dell'oggetto collegato al lock. Le versioni degli oggetti figli permettono al server di sapere se un particolare oggetto è diverso da quello di cui si vuol prendere un lock. Per esempio una delle procedure contenute in una videata, presente nella copia master potrebbe avere un numero di versione superiore alla corrispondente procedura presente nella copia client, quindi il lock di tipo contenuto sulla videata non deve essere fornito dato che la copia locale è più vecchia della copia master. In questo caso occorre prima recuperare l'ultima versione della procedura poi, una volta che tutti i figli della videata e la videata stessa sono allineati ai corrispondenti oggetti della copia master, il lock di tipo contenuto verrà concesso.
Se si verifica il caso descritto sopra, ovvero il tentativo di prendere un lock su un oggetto che contiene figli non allineati alla copia master, Instant Developer propone di recuperare automaticamente l'ultima versione dell'oggetto prima di fornire il lock. Se il programmatore autorizza l'operazione, Instant Developer aggiorna l'oggetto recuperando l'ultima versione dello stesso dal server poi effettua nuovamente la richiesta del lock.
Ogni volta che un oggetto all'interno della copia client viene modificato Instant Developer verifica, come già descritto, la disponibilità di un apposito lock che permetta la modifica. Qualora il lock non esista contatta il server e richiede automaticamente un lock. Qualora il lock preso in automatico non sia quello desiderato è possibile richiedere manualmente tale lock. Per farlo è possibile selezionare la voce Check Out dal menù contestuale dell'oggetto di cui si desidera il lock. Instant Developer presenterà un'apposita videata tramite la quale possiamo specificare i dettagli del lock richiesto:
Videata mostrata quando si tenta di prendere un lock su un oggetto tramite il comando del menù contestuale.
Come mostrato in figura possiamo indicare se il lock richiesto è di tipo Contenuto, e quindi riguarda l'oggetto ed i suoi figli, o solo di tipo Oggetto. Possiamo anche specificare se desideriamo un lock normale o desideriamo forzare l'ottenimento del lock. In questo caso il server disabilita tutti i controlli di versione fornendo il lock anche se le versioni o il numero dei figli presenti nella copia master non corrisponde con quello presente nella copia locale. Questa operazione può essere necessaria se siamo sicuri che la copia locale dell'oggetto è quella corretta ed è quella che andrà inserita nella copia master quando effettueeremo l'operazione di Check In. Possiamo anche prendere un lock temporaneo, ovvero un lock che viene preso solo sulla copia locale e non interferisce con l'operatività degli altri programmatori.
Questo messaggio informa che l'oggetto presente nella copia locale è più vecchio di quello presente nella copia master e quindi non è possibile fornire un lock sullo stesso. Per risolvere il problema dobbiamo decidere quale oggetto è quello che vogliamo diventi quello definitivo. Se riteniamo che l'oggetto presente nella copia client sia quello giusto possiamo forzare l'ottenimento del lock come descritto prima. Se, invece, riteniamo che la copia presente nel server sia quella corretta occorre recuperare l'ultima versione dell'oggetto per alinearci alla copia master. Solo allora sarà possibile ottenere il lock desiderato.
Il messaggio indica che l'utente %2 possiede un lock sull'oggetto %3 e questo lock non permette di prendere un lock sull'oggetto %1. Questa condizione si presenta, per esempio, quando l'utente %2 possiede un lock su una videata che contiene un pannello. Se un altro utente tenta di modificare un campo del database e quel campo è usato, per esempio, nella query del pannello si ottiene il messaggio indicato: il campo del database non può essere modificato dato che quella modifica richiederebbe una ulteriore modifica alla colonna della query del pannello. Ma tale ulteriore modifica richiederebbe un lock sulla videata che però è già posseduta da un altro utente. Solo se il lock sulla videata fosse già a disposizione dell'utente che sta modificando il campo tale modifica sarebbe permessa. Per risolvere il problema occorre attendere che l'utente %2 termini la modifica sull'oggetto %3 affinché la modifica sull'oggetto %1 sia permessa.
Si è verificato un errore durante l'inserimento di un lock sul database. 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 il servizio di assistenza.
L'oggetto %1 non può essere bloccato perché bloccando quell'oggetto non dovrebbe essere possibile ottenere lock di tipo contenuto sui padri dell'oggetto stesso. Ma l'oggetto %2, che è uno dei padri dell'oggetto %1, è già bloccato con un lock di contenuto dall'utente %3. Per esempio: supponiamo che l'utente A possegga un lock su una procedura P contenuta in una videata V contenuta, a sua volta, nel folder F. In questa situazione nessun'altro utente potrà ottenere un lock di contenuto sulla videata V dato che questo lock permetterebbe di modificare la videata e qualsiasi figlio della stessa qundi anche la sua procedura P. Se un altro utente tenta di bloccare la videata V con un lock di tipo contenuto il sistema vede che la videata non è bloccata da nessun'altro utente quindi sarebbe tentato di autorizzare tale blocco. Ma poi scopre che un lock sulla procedura P dell'utente A ha anche inserito un divieto di lock sul folder F quindi risponde al client comunicando che la videata V non può essere bloccata perchè tale operazione richiedebbe che nessuno possa bloccare i padri della videata ma il folder F è già bloccato dall'utente A.
Il messaggio indica che l'oggetto %1, presente sulla copia master, non possiede lo stesso numero di figli della copia locale. Questo problema è molto probabilmente dovuto al fatto che un altro programmatore ha inserito o eliminato un oggetto figlio dell'oggetto %1 ed il server si rifiuta di fornire il lock. Per risolvere il problema occorre decidere se la copia locale è quella corretta o meno. Se riteniamo che i figli presenti nella copia locale siano quelli giusti possiamo forzare la presa del lock come descritto nell'articolo. Altrimenti possiamo prima recuperare l'ultima versione dell'oggetto e poi rieseguire la modifica.
Il messaggio indica che l'oggetto %2 non esiste più sulla copia master quindi il server non può fornire un lock su di lui. Anche qui possiamo forzare la presa del lock se vogliamo che l'oggetto torni nella copia master. Se invece vogliamo eliminare l'oggetto dalla copia locale non possiamo semplicemente cancellarlo dato che questo richiederebbe un lock di tipo eliminato sull'oggetto che però non verrà fornito dal server dato che l'oggetto non esiste sulla copia master. Dobbiamo solo recuperare l'ultima versione di uno dei padri dell'oggetto affinché questo venga eliminato dalla copia locale.
Il messaggio indica che l'utente %2 sta già modificando l'oggetto %1 ed il server non permette di modificare simultaneamente lo stesso oggetto da più di un utente alla volta. Il lock sarà concesso solo quando l'utente %2 ha terminato la modifica ed avrà effettuato il check in dell'oggetto.
Tale messaggio è analogo al messaggio 6185 ed indica che l'oggetto %1 è più vecchio di quello presente sul server.
Si è verificato un errore durante la lettura della lista dei lock già presenti sul database. Tale operazione viene eseguita dal server durante la verifica del numero e della versione dei figli dell'oggetto e permette al server di non contare oggetti che sono ancora presenti nella copia master ma non più presenti nella copia client dato che questi sono stati, appunto, cancellati.
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 il servizio di assistenza.
Ultima modifica: 20/09/2008 / Validità: da 7.5.3400