Ciao,
>
>così senza conoscere bene lo scenario e immaginando che i vari
>server di cui parli siano "remoti" tra di loro, mi lascia un
>attimo perplesso
>la scelta del TRIGGER in quanto, soprattutto se poi i server
>aumentassero, vincola la transazione di inserimento al fatto
>che tutti i server coinvolti
>siano disponibili. Se uno di questi non lo fosse, per problemi
>di connettività o manutenzione, ecc., l'inserimento dell'articolo
>fallirebbe per tutti (quindi.
>può anche essere che tale scelta tu l'abbia fatta apposta per
>questo motivo)....
>
Come avevo detto le tre aziende usano tre database distinti ma devo aggiungere, visto che l' avevo tralasciato, che
i tre database si trovano sulla stessa istanza sql 2005 in un unico server.
>Avevi già valutato la soluzione di una replica, asincrona rispetto
>alla transazione, sfruttando i sistemi di replica forniti da
>SQL Server?
>
>Potresti avere il database principale che espone la replica di
>una serie di aggetti (es. la tabella Articoli), ogni server "secondario"
>si iscriverebbe a tale replica.
>Quindi, alla definizione di un nuovo server secondario, si tratterebbe
>di eseguire (via script) la sottoscrizione alla replica in questione.
>
>Se tale replica fosse di tipo "Transactional" (le altre tipologie
>che ricordo sono Snapshot e Merge) otterresti che ogni operazione
>effettuata sul master
>verrebbe riprodotta sui server "iscritti" o al momento o ad esempio
>ogni n minuti, ecc.
>
Visto che devo sincronizzare solo alcuni attributi (con delle eventuali conversioni - cioè ad esempio, l' attributo "A" se ha valore 1 per un'azienda potrei doverlo convertire in 2 per un' altra e lasciarlo ad 1 per l'altra ancora) preferisco usare un unico trigger sull' azienda in cui vengono gestiti (in termini di inserimento, aggiornamento e cancellazione) gli articoli.
Riporto il trigger completo, cosi magari mi potete suggerire se c'è un modo per ovviare ai cursori.
Grazie Michele!
>Michele