Newsgroup: it.comp.appl.access
Titolo: E' il caso di Replicare?

La realtà è la seguente:
ho prodotto un DB access 97 per l'archiviazione, la ricerca e la
stampa di dati di mosaici, immagini comprese.
In corso d'opera (non è che avessero le idee chiare fin dall'inizio) è
venuto fuori che questo DB sarebbe meglio (anzi ormai indispensabile)
che venisse utilizzato in multiutenza e quindi sto valutando le varie
opportunità.
1 - la replica del db
2 - un sistema client/server via internet
Parlando con i clienti sembra che la replica, per le sue
caratteristiche, sia proprio la soluzione che cercano.
Il db assumerà le dimensioni di circa 500.000 mosaici (x una ventina
di tabelle con immagini = un bel paccone).
La domande vertono quindi sulla prima soluzione: la replica.
- L'uso delle repliche è prassi comune nel mondo commerciale oppure si
è dimostrato che non ne vale la pena?
- E' possibile gestire autonomamente la risoluzione dei conflitti? E
magari anche la loro individuazione?
- Il partial replica wizard o comunque la gestione di repliche
parziali via DAO è funzionale o è da diventare matti?
- La gestione della protezione a livello utente è comunque possibile?
- Una volta replicato il DB, si ha comunque la possibilità di
dividerlo in FE/BE?
Se non l'avete notato ve lo confesso io: non so praticamente nulla
delle repliche, a parte come funzionano a livello base.
Grazie mille per le delucidazioni che arriveranno!
Marco.

 2 - un sistema client/server via internet
Dovresti passare SQL-Server poichè è un DB concepito per lavorare in
client/server
io tempo fa avevo creato una gestione magazzino in cui i dati di sedi
periferiche venivano
centrallizate su un server remoto e le prestazioni erano accettabili.

 dividerlo in FE/BE?
Ops!!!! che mi hai chiesto? Vorresti dire che non lo è già? La replica è
utile solitamente per problemi strutturali (variazioni di tabelle) ma non
vorrai mica fare la replica del FE... a che ti servirebbe?!... per quello
basta un exe di installazione
--
Maurizio75

 ha scritto nel messaggio
news:k8Q2PRukuLUix+...@4ax.com...

Ti posso dire come gestirei io la cosa.
C'è un server centrale a cui arrivano via mail i nuovi record. Attenzione xò
a come gestisci le immagini: 500.000 sono troppissime, usa quindi
collegamenti col percorso.
ovviamente essendo le tabelle di aggiornamento sempre uguali nella struttura
automatizzi l'importazione.
nel tuo db non accettare duplicati.
pubblica tutto su web così mostrerai ai tuoi client i risultati
Se ti piace l'idea si può entrare nei particolari
ciao MAssimiliano


Intendi dire che un db replicato è comunque + lento di uno normale?  E
se si, lo è in modo molto percettibile oppure è una cosa accettabile?
Il cliente intende poter dare il db a vari collaboratori che se lo
tengono, chessò, un mese e poi tornano e scaricano tutto quello che
hanno fatto nel db master.
Inoltre, in un eventuale futuro, vorrebbero poter
distribuire/commercializzare delle copie del db contenenti
sottoinsiemi dei dati contenuti nel master. Una roba tipo "CD delle
leggi del 2002" per gli avvocati.
Oppure permettere il collegamento da remoto per la consultazione, ma
non sanno bene neanche loro.


basta un exe di installazione
Il cliente intende poter dare il db a vari collaboratori che se lo
tengono, chessò, un mese e poi tornano e scaricano tutto quello che
hanno fatto nel db master.
Inoltre, in un eventuale futuro, vorrebbero poter
distribuire/commercializzare delle copie del db contenenti
sottoinsiemi dei dati contenuti nel master. Una roba tipo "CD delle
leggi del 2002" per gli avvocati.
Oppure permettere il collegamento da remoto per la consultazione, ma
non sanno bene neanche loro.
In tali eventualità, non è assolutamente improbabile che mi saltino
fuori (dopo che abbiamo fatto le repliche e compagnia bella) col
discorso: "Beh, abbiamo comprato un server. Dividiamo il DB così
centralizziamo i dati e diamo in giro i FE?"
In questa ottica, mi piacerebbe sapere se repliche e divisione del db
sono compatibili tra loro o meno.



Via mail? Mi sa che hanno bisogno di qualcosa di un po più "real
time".
Però mi hai reso curioso... com'è che si farebbe 'sta cosa?

 Però mi hai reso curioso... com'è che si farebbe 'sta cosa?
Massimiliano ancora:
Hai detto che la sincronizzazione avverrebbe per ciascun agente una volta al
mese, in relatà potrebbe avvenire ogni volta che si vuole. In realtà per
come la vedo io, Tizio parte col BE aggiornato, fa tutte le sue operazioni,
se ha bisogno di consultare dati aggiornatissimi si collega (magari col
GPRS) al sito ufficiale e consulta ciò che vuole o si scarica in ftp il
database aggionatissimo. A fine serata o quando vuole ti invia le nuove
vendite e tu con una procedura automatizzata acquisisci sul server e
pubblichi il tutto. Un ulteriore consiglio: se installi un server sul tuo pc
tipo Apache e gestisci l'ftp direttamente (ferme restando tutte le
problematiche di protezione), non hai delay nell'aggiornamento.
E' una via percorribile, l'ho già fatto col mio team, fammi sapere.
MAssimiliano

pubblichi il tutto.
 dai per scontato che non avvengano mai modifiche all'intero insieme
dei dati. Il db, purtroppo, non tratta argomenti commerciali, ma
archeologici, e potrebbe darsi che da remoto vengano sia inseriti, che
cancellati, che modificati anche i record di base.
Scaricare i record nuovi, quindi, non sarebbe probabilmente molto
vicino alla realtà. Dovrebbe forse trattarsi di una sincronizzazione
da remoto, ma i tempi? e le immagini?
Se invece NON permetto la sincronia o il collegamento da remoto, e
molto più semplicemente creo FE/BE e db replicato, mi confermi che
potrei fare le cose seguenti?
- Permettere ad un utente qualsiasi di andare presso il master,
crearsi la replica (magari con solamente un subset dei dati), andar
via e lavorarci, e dopo un pò tornare e sincronizzare tutto.
- Distribuire CD con il solo FE e permettere, all'interno
dell'ambiente di lavoro, di lavorare direttamente sul master BE.
- Disrtibuire CD con FE/BE e subset dei dati per la sola
consultazione.
Scusa la lunghezza, ma mi trovo ad affrontare per la prima volta
questo tipo di problemi..
Grazie infinite.
Marco.

 consultazione.
Lo puoi ottenere anche con la mia soluzione, ferma restando la non
scrivibilità (in questo senso) di un supporto come il cd.
In buona sostanza credo sia meglio che gestisca tu le variazioni, avendo al
disponibilità di tutto lo storico, la soluzione web permette un aggionamento
costante e non c'è la necessità (fermo restando l'eventuale piacere) di
incontrare i client.
Confido infine nella buona soddisfazione che può dare tale soddisfazione.
Infine una proposta: se vuoi possiamo fare una simulazione. Se ho tempo in
questo week end preparo un piccolo db come lo intendo io e faccio il client
e ti lascio gestire il server.
fammi sapere presto.
ciao MAssimiliano


Beh, sono generalmente d'accordo con te e ti ringrazio di tutto il
tempo che stai perdendo.
Parlando coi clienti dei futuri sviluppi di questo db, era chiaro che
la soluzione via web potesse essere quella potenzialmente più
flessibile e completa. Ma anche quella che richiedeva più risorse in
termini di programmazione, costi di sviluppo e configurazione del
server, etc.
L'alternativa sembrava essere la replica di access.
Mi piacerebbe moltissimo fare quella simulazione di cui parlavi, ma,
per non farti perdere tempo, vorrei prima parlare col cliente dopo
avere avuto le risposte alle domande che ti pongo sopra. Nel caso lui
decidesse che "Web è meglio" allora magari ti disturberò di nuovo.
Che dici?
Ancora grazie.
Marco.