Filemeker Server e Client: dubbi per sviluppo programma

[Pimpinelli]

Però forse sono arrivato ad un compromesso.
Potrei fare in modo che ogni record creato in locale abbia un ID autogenerato (magari con data + ora oppure utente + lingua o semplicemente un numero id random unico). Cosicché una volta scaricato sul server, mantenga quella stringa. Se un record viene modificato da remoto allora viene aggiunto (in un altro campo ID autogenerato 2) un nuovo ID per quella scheda. Partendo dal presupposto che il server sia il luogo principale dove risiederanno tutte le schede aggiornate, potrei fare in modo che all'avvio il programma in locale controlli se le sue schede sono aggiornate con quelle del server ovvero :

se l'ID autogenerato 2 è diverso da 0, copia il record del server sostituendolo sul file in locale
se l'ID autogenerato 2 è vuoto, non fa niente perché non ci sono state modifiche fatte.
gli altri record che non sono presenti, vengono semplicemente inseriti sul server

Credo che così possa tenere aggiornato il programma in locale ed evitare doppioni ed errori... poi è chiaro che starà anche a loro fare un po' di attenzione. Magari se strutturo tutto con script e messaggi a finestra, riesco ad evitare che facciano casino.

Voi che ne pensate?

[Pimpinelli]

significa che ogni utente ha la possibilità di vedere solo i record a lui assegnati.

E mi pare che sia la strada migliore... alla fine al tecnico spagnolo, non importa di vedere il prodotto in russo o in inglese, ecc...
Diciamo che sarà poi l'admin del programma sul server che potrà vedersi quali prodotti sono in spagnolo, quali quelli in turco ecc... farsi le liste e stampare le schede.

[moro]

potrei fare in modo che all'avvio il programma in locale controlli se le sue schede sono aggiornate con quelle del server ovvero

Non può andare.
Supponi le modifiche al server vengano fatte dopo aver avviato il db su client.
Se possibile io limiterei le modifiche delle schede solo ai client ma divisi in categoria. Il server potrà solo importare e visionare altrimenti si crea confusione.
Se non va bene così dovrai pensare ad altro.

[Pimpinelli]

Se possibile io limiterei le modifiche delle schede solo ai client ma divisi in categoria. Il server potrà solo importare e visionare altrimenti si crea confusione.

Okay, in pratica come dici tu il programma sul server funge solo da raccoglitore di informazioni, in parole povere (e forse manco corrette) potrei dire che funga quasi da GUI per coloro che poi devono stampare, ordinare e creare le liste... mentre se ci sono degli errori ad esempio di battitura, sta all'utente client correggerle e ripassarle sul server....

Ho interpretato bene la cosa?
Se fosse così penso che potrebbe essere l'ideale...

Grazie di nuovo per il suggerimento.

[orpone70]

Mi piacerebbe sapere come si fa la sincronizzazione dei dati. Ammesso che decida di destinare 10 record a pinco e 10 record a pallino, al loro rientro si collegano al server ed a questo punto filemaker che fa? prende i due file e li sincronizza ? come ? E se il file dell'utente pinco si è corrotto non si rischia di corrompere anche quello del server ? se pallino decide di eliminare un record lo fa anche la sincronizzazione ?

E pensare che uno dei motivi che mi hanno spinto ad adottare fm come database è stato quello di immettere, modificare e visionare in tempo reale dati da qualsiasi punto mi trovassi, da casa, da un cliente ect, senza dover ricorrere alle fastidiose sincronizzazioni.

[Pimpinelli]

E pensare che uno dei motivi che mi hanno spinto ad adottare fm come database è stato quello di immettere, modificare e visionare in tempo reale dati da qualsiasi punto mi trovassi, da casa, da un cliente ect, senza dover ricorrere alle fastidiose sincronizzazioni.

Ciao,
beh è la prima cosa che avevo proposto al cliente... ma capisco anche che non sempre internet è disponibile, soprattutto in alcune zone del mondo dove hanno esigenza di recarsi per lavoro (anche se a me sembra molto dubbia 'sta cosa)... sicché ecco il motivo dell'irritante (concordo) soluzione di sincronizzazione.

Per quanto riguardo il resto, quello che decide tutto a questo punto diventa il client, il server è slave di ciò che i vari client gli passano... sul discorso della corruzione... beh non saprei, non mi è mai capitato, però esista questa problematica... ma a quel punto sarà la macchina (server) a backuppare qualsiasi creando sezioni separate giornaliere... alla fine voglio dire, mica posso risolvergli il problema se gli va via la corrente e si corrompe un file....

[stregatto]

mica posso risolvergli il problema se gli va via la corrente e si corrompe un file

certo che devi. Se la soluzione è a rischio corruzione il responsabile sei tu.

.g.

[Pimpinelli]

certo che devi. Se la soluzione è a rischio corruzione il responsabile sei tu.

Uhm... quando il server è settato per fare i backup, e quando io ho creato uno script per i file client che faccia un semplice backup (copia con nome), penso di essere a posto. (Sennò gli vendo anche un PSU APC)
Cmq, penso che alla fine quello sarebbe il male minore... penso già a riprogrammare tutto :/

Cmq di che licenze avrei bisogno? Server Advanced + Filemaker Advanced? (Considerando che dovrò sviluppare l'applicazione sia per il server che per il client e mi servirà una licenza dell'11 anche per me... perché sono rimasto alla 8.5)

[stregatto]

vuoi sapere come farei io?
N runtime (una per cliente)
1FMS (o anche FMP, o al limite anche una runtime centrale, dipende da cosa ci devono fare).
procedura di aggiornamento via ftp.

.g.

[moro]

N runtime (una per cliente)
1FMS (o anche FMP, o al limite anche una runtime centrale, dipende da cosa ci devono fare).
procedura di aggiornamento via ftp.

Direi ottima come idea, risparmi licenze e i client non saranno costretti a tornare per forza alla base per aggiornare il server ma se la quantità dadi è molta sarà lento nel trasferimento.