IDManager vs Cambio tipo campo chiave

[r.bianco]

In riferimento a questo post:

viewtopic.php?uid=84&f=5&t=72307&start=0

Nel caso in cui IDManager non fa tutto quello che potrebbe/dovrebbe, i motivi possono essere due:

a. limite tecnico
b. limite auto imposto da InDe

Nel caso b., InDe sa che 'sarebbe da fare' ma non lo fa. La soluzione è modificare il ddl con quelle istruzioni che InDe non mette perché considerate pericolose.
Allo stato attuale, l'unico modo per capire se siamo in questo caso è fare una pubblicazione e aspettare l'errore. Oltre alla perdita di tempo, questo può creare molti problemi nel caso in cui il db non permetta il rollback delle modifiche (per esempio un disallineamento tra la struttura e il contenuto della zz_object).
Propongo che, in fase di pubblicazione, InDe avverta che ci sono delle istruzioni che decide di non mettere, in modo da sapere prima che qualcosa non va.
Inoltre, sarebbe molto bello se InDe indicasse tali istruzioni, senza metterle nel ddl.

[lucabaldini]

Non mi è chiaro. Se ci sono comandi che non possono essere eseguiti la pubblicazione fallisce in fase di verifica. Se InDe arriva a proporre l'invio dei dati di pubblicazione è perché il DB non contiene modifiche che non possono essere fate... Non mi torna...

Tra l'altro io non lavoro così. Non faccio tentativi in produzione ma ho un database in locale che è allineato alla versione del cliente. Opero su quello (dopo aver fatto un backup) e se tutto va a buon fine, pubblico in produzione.

Puoi spiegare meglio il caso?

[r.bianco]

Nel caso specifico, devo modificare un campo chiave da char fixed a varchar: TAB_DPI.DPI_COD

Nella logica che ho 'intuito' leggendo il ddl, InDe esegue questi quattro passaggi:
1. Elimina la definizione di PK dalla tabella (TAB_DPI_PK)
2. Esegue la modifica del campo (DPI_COD)
3. Crea la definizione di PK dalla tabella (TAB_DPI_PK)
4. Aggiorna zz_sync

Il ddl creato contiene questa istruzione 'mozzata':

Code: Select all

>> alter table TAB_DPI drop constraint |


Come puoi notare (e se ho capito bene), manca il nome dell'oggetto da eliminare, l'istruzione completa dovrebbe essere:

Code: Select all

alter table TAB_DPI drop constraint TAB_DPI_PK;

IDManager non mi da alcun avviso, io lancio l'aggiornamento e questo fallisce.



Queste prove le stiamo eseguendo, come suggerisci tu, in un'area di test e non in produzione. C'è però da tener conto di questo:

1. Non abbiamo un unico db di test, ma uno per ogni azienda. IDManager (in area di test) è configurato per aggiornarli tutti.
2. Non tutti gli sviluppatori hanno le competenze/i diritti/ gli strumenti per eseguire bk e ripristino di db.

Eseguire un bk di tutti i db ad ogni modifica nella struttura diventerebbe un problema.

[lucabaldini]

Il fatto che l'istruzione sia "mozzata" è il problema... e va capito perché in quel caso non c'è il nome della PK... per analizzare il problema dovrei avere un DB con la stessa ZZ_OBJECTS che c'è in produzione, il progetto e capire perché InDe, data la ZZ_OBJECTS e il progetto non mette il nome della PK. Non è facile per me capire in quale caso non funziona... e il forum non aiuta in questo caso.

Il fatto che IDManager non dica nulla è corretto... perché la riga inizia con >> che vuol dire "esegui l'istruzione e se dà errore perché il constraint non c'è, prosegui". Il problema è che in questo caso specifico (a causa del bug di cui sopra) l'errore non è dovuto all'assenza della PK bensì al bug... quindi la PK non viene rimossa generando errori quando viene poi effettuata la modifica.

Io controllo sempre, prima di pubblicare, il DDL che viene generato da InDe prima di inviare il job in produzione. InDe non è uno strumento perfetto (purtroppo non ne esistono) e può sbagliare... e il fidarsi sempre e troppo può generare problemi che, poi, devo risolvere manualmente. Te lo dico io che sviluppo in C++ dentro InDe ed io stesso, quando pubblico le nostre app, verifico sempre e comunque quel che viene generato e, se posso, faccio backup. Non ho mai avuto problemi e questo mi fa felice... ma sono certo che la prima volta che salterò i controlli succederà qualcosa che mi farà fare il triplo della fatica vanificando del tutto l'uso di IDManager.

Venendo al problema. Ti chiederei se possibile di inviare come segnalazione di malfunzionamento il progetto (eventualmente anche solo un progetto vuoto con il DB) e, possibilemente, un backup del database... se vuoi puoi anche duplicare il database ed eliminare tutte le tabelle a parte la ZZ_OBJECTS... così il backup è piccolo... è chiaro che richiede del tempo per farlo ma io non ho altra soluzione se non quella di analizzare un caso specifico... è moldo difficile e rischioso correggere errori che non posso vedere...

[r.bianco]

Tutto chiaro, grazie.

[r.bianco]

Detto fatto :)

[lucabaldini]

GRAZIE! :-))))