Aiuto per libreria di sincronizzazione db firebird

[nomorelogic]

Non hai torto quando dici di voler evitare di scrivere tutti i campi, specie se non sono stati modificati.
Se però pensi alla correttezza della replicazione (tralasciamo le performance), cosa capita se per aggiornare un record hai bisogno di 10 update e ne vanno a buon fine solo 3? Bisognerebbe lavorare con le transazioni ma sarebbe una complicazione inutile in quanto, con una unica UPDATE, risolvi tutto.
Più che altro puoi limitare l'istruzione UPDATE ai soli campi che ti interessano per la replicazione, tralasciando gli altri.

Poi ti consiglio di fare in modo che nella WHERE finiscano solo i campi della chiave primaria.

Domanda:
si tratta di una replicazione unidirezionale?

[xinyiman]

Si la where è già studiata così. Si per il momento è unidirezionale. In quanto la libreria crea una tabella T_Log ( o come preferisci chiamarla) e li mette tutti i movimenti di insert, update e delete di tutte le tabelle del database (ovviamente di tutte le tabelle e i campi presenti al momento dell'installazione dei trigger da parte della mia libreria, in caso si andassero ad aggiornare i campi di una tabella o si creasse una nuova tabella o si distruggesse una nuova tabella sarebbe opportuno rilanciare il software che comprende la mia libreria). Poi la mia libreria ha una funzione per l'esportazione delle query contenute nella T_Log in un file. Ergo ne fai quello che vuoi. (nel mio caso reimportarle in un altro DB)

[nomorelogic]

quindi l'import lo fai manualmente?

[xinyiman]

quindi l'import lo fai manualmente?

Devo poi creare una funzione per l'import

[nomorelogic]

se ti può interessare dai un'occhiata al seguente link (è un mio progetto)
http://sourceforge.net/projects/dbupdaterxs/

si tratta di un progetto che serve ad aggiornare un database fornendo una cartella con dentro degli script
l'aggiornamento viene tracciato all'interno del database stesso in modo che sai esattamente a che script sei arrivato (ed hai la certezza che non venga eseguito 2 volte uno stesso script)

puoi sia utilizzare le classi che usarlo come procedura schedulata

[xinyiman]

Grazie gli darò un occhiata, anche se per il mio utilizzo l'import sarà fatto in php

[xinyiman]

Progetto interessante il tuo
Me lo descrivi un po' più nel dettaglio? Da cosa è nata la tua esigenza di farlo?

[nomorelogic]

è una riscrittura di un tool fatto con delphi che usiamo in azienda
questa versione è diversa in quanto è fatta con lazarus, è open source, è multidatabase e multiprogetto (solo che la sto usando poco, magari c'è qualche bug in giro)

fondamentalmente serve per tenere aggiornati N database secondo una lista di script
quando faccio delle modifiche al gestionale: (1) genero gli script (2) li distribuisco ai clienti e (3) loro ci aggiornano il loro database

Edit:
l'esigenza è venuta pensando ad un gestionale cross OS e cross DB, ma è solo un pensiero

[nomorelogic]

Grazie gli darò un occhiata, anche se per il mio utilizzo l'import sarà fatto in php

beh, se lo puoi installare sul server dove gira apache...

[xinyiman]

Allora passo avanti, ora dovrebbe funzionare adeguatamente. Ho bisogno di tester, chi mi testa il risultato su dei suoi database? (vi suggerisco di farlo sulle copie).

Compilate il progetto, inseriti i parametri di connessione al vostro db. Premete sul tasto [CONNETTI] poi premete [INSTALLAZIONE TRIGGER E TABELLA LOG], ora andate a fare delle modifiche sui vostri db, fatene diverse e variegate, se qualcuno ha dei campi BLOB ben vengano come test. Poi premete il tasto [ESTRAI DATI].

Attenzione vi consiglio di lanciare il progetto non come debug, ma dopo la compilazione chiudere lazarus e lanciare l'eseguibile.

Attendo vostre notizie