it:renameissue
Differenze
Queste sono le differenze tra la revisione selezionata e la versione attuale della pagina.
— | it:renameissue [2021/03/25 13:09] (versione attuale) – creata - modifica esterna 127.0.0.1 | ||
---|---|---|---|
Linea 1: | Linea 1: | ||
+ | TitleTAG | ||
+ | |||
+ | |||
+ | |||
+ | < | ||
+ | |||
+ | Per il caso di RENAME è stato riscontrato un comportamento particolare e che potrebbe causare la creazione di log di errori (falsi positivi): vi segnaliamo la casistica in attesa di trovare una soluzione. | ||
+ | |||
+ | **Gestione dell' | ||
+ | |||
+ | La gestione del RENAME è particolare, | ||
+ | |||
+ | Purtroppo questa gestione ha un effetto collaterale per il metodo di rilevamento delle modifiche utilizzato da Sprinkler: in particolare, | ||
+ | |||
+ | Caso RENAME + MODIFY: il sistema di destinazione riceve una segnalazione di RENAME e la replica direttamente, | ||
+ | |||
+ | Caso RENAME + RENAME: si genera un problema quando il campo modificato è referenziato da una chiave. Pensiamo per esempio di avere in replica sia la tabella [Customer] che la tabella [Customer Bank Accont]: in questo caso, la chiave [No.] di [Customer] è referenziata dal campo [Customer No.] della chiave di [Customer Bank Account]. Se rinominiamo un Cliente, quando il sistema Target applicherà il primo RENAME effettuerà in automatico anche un RENAME delle righe della [Customer Bank Account] di quel Cliente. | ||
+ | |||
+ | Sprinkler in questo caso segnalerà un RENAME del Cliente e un RENAME di un record corrispondente della [Customer Bank Account]. Il secondo RENAME però non troverà tramite la chiave il record cercato, perché __già rinominato__ direttamente da Dynamics 365 Business Central durante l' | ||
+ | |||