Alcuni grossi problemi di MW

Guido Gio 16 Feb 2012 - 0:22

Uso MW da poco piu' di due mesi.
Ci sono tante cose pregevoli, quali per es. l'interfaccia, la possibilita' di fare ricerche di tutti i tipi, ma mi lasciano perplesso alcune grosse lacune nella attivita' routinaria.
Per es, quello che ho constatato solo oggi, ma ogni giorno c'e' una novita':

1) se un paz. era risultato in passato intollerante ad un farmaco ora non piu' in produzione, non e' piu' possibile selezionarlo dall'elenco farmaci. Si puo' pero' digitare il nome della molecola a mano libera nel campo apposito, ma e questo e' grave, non si puo' inserire in alcun modo il suo vecchio codice ATC, cosicche' il programma non puo' piu' applicare alcun automatismo nell'avviso di possibili intolleranze con un altro farmaco che si sta prescrivendo.

2) perche' lo stramaledetto programma avvisa solo in fase di stampa di una possibile interazione tra un nuovo farmaco prescritto e i farmaci gia' in uso continuativo da parte del paziente ? Non sarebbe stato possibile avvisare della interazione in fase di inserimento del nuovo farmaco, come faceva il mio vecchio programma ? Inoltre se e' un farmaco in fascia C, io non lo stampo perche' scrivo le ricette bianche a mano, quindi non verrei mai avvisato. A meno che per ogni nuova prescrizione attivi il comando "trova interazioni", ma e' improponibile.

3) questo l'ho gia' segnalato sulla mailing list di Yahoo: se prescrivo un farmaco o un accertamento tabellare errato, non posso piu' sovrascriverlo con il farmaco/accertamenento corretto perche' il record diventa immodificabile anche prima di stamparlo. Posso solo cancellarlo (seleziona, cancella, aggiungi il nuovo record: uffaaa) interamente. Ma qui tocchiamo il ridicolo: un farmaco gia' stampato diventa giustamente immodificabile (anche da chi l' ha prescritto) ma e' possibile modificare, magari accidentalmente, il numero di pezzi prescritti (per es. da 2 a 4) con tutti i contenziosi che ne possono nascere con il paziente !

4) stendiamo un velo pietoso sull'editor dei moduli configurabili, di cui ho gia' parlato in altro topic.

5) l'elenco potrebbe continuare che tra l'altro erano tutti problemi da me constatati e risolti dieci anni fa nel mio vecchio programma.

Insomma, se alla Dedalus invece di stare appresso a tutti gli add-on a pagamento (acn, net, rpg) curassero meglio il programma base avrebbero utenti un po' piu' contenti. Io stasera, alla ennesima imprecazione stavo gia' pensando seriamente di ricambiare programma.

Guido

Guido Sab 3 Mar 2012 - 18:17

Prosegue la mia carrellata:

PROBLEMA CON IL SINCRO.

Probabilmente gli utenti piu' esperti di Millewin conosceranno questo inconveniente, che mi ha fatto tribolare un po', malgrado una consulenza chiesta via email alla dedalus.
Il problema si crea quando dopo aver creato un sincro.db (per es. in casa), lo si trasporta su un'altra postazione (per.es. studio) senza cancellare il sicro.db originale o senza disattivare l'abilitazione al RRS Locale nel PC di origine, in modo da non effettuare nessuna sincronizzazione ulteriore neanche per un attimo.
Se si rieffettua una sincronizzazione in casa, quando si ritrasferisce il sincro dello studio nella postazione di casa, non verranno trasferiti tutti i dati modificati e/o creati nello studio, ma solo quelli intermedi tra l'ultima sincronizzazione effettuata in studio e l'ultima effettuata in casa.
Come caso estremo se l'ultima sincronizzazione effettuata in casa e' posteriore all'ultima dello studio, anche solo consultando i dati di un unico paziente, viene trasferito solo quell'unico paziente dal Mille.db di casa al sincro dello studio, e nessun dato nella direzione opposta.
Possibile che alla Dedalus non abbiano ben messo in evidenza che la sincronizzazione nel Millewin di origine deve essere disabilitata permanentemente ?
La soluzione del problema a mio parere sarebbe molto semplice con un poco di programmazione aggiuntiva, o semplicemente scrivendolo nel manuale chiaramente.Ma evidentemente sono troppo occupati per fare cio'.

PROBLEMA CON I NUOVI ACCERTAMENTI INSERITI DALL'UTENTE:

Se un utente aggiunge un accertamento nuovo (Custom) nella tabella Accertamenti,
per es. un esame di laboratorio, si aspetta che con la successiva
sincronizzazione quel nuovo accertamento possa essere trasferito su un altro PC.
Cio' non avviene, perche' come saprete e come ho scoperto nei vari forum (NON NEL MANUALE e lo sottolineo) i dati modificati negli elenchi tabellari non sono compresi nella sincronizzazione.
Fin qui potrebbe sembrare un inconveniente fastidioso e nulla di piu', ma qui si crea un problema piu' grave.
Supponiamo che nel PC (1) io abbia aggiunto l'esame di laboratorio (A) in
tabella accertamenti, e prescrivo quell'accertamento al paziente (X).
Poi successivamente aggiungo un altro esame di laboratorio (B) nella tabella accertamenti nel PC (2).
Quando effettuo una risincronizzazione tra il PC (1) e il (2) il paziente (X)
con il suo accertamento (A) gia' prescritto va a finire sul PC (2).
Se adesso dal PC (2) l'utente seleziona il paziente (X), seleziona gli esami di
laboratorio gia' prescritti e li riprescrive copiandoli con il comando CTRL+F6, ecco che senza che NIENTE LO AVVISI l'esame di laboratorio (A) viene trasformato
in (B), e se gli esami riprescritti sono molti l'utente potrebbe non accorgersi di questa silenziosa trasformazione.

Spiegazione per i non esperti: l'inconveniente si genera' perche' i codici CO_TAB_ACC e ROWID che identificano i singoli accertamenti nella tabella TAB_ACC sono univoci solo in parte; quando l'utente aggiunge un altro accertamento nuovo il codice generato e' invece un semplice numero progressivo del tipo C001, C002 etc.
Quindi e' facile, anzi inevitabile, che due accertamenti nuovi e completamente diversi, inseriti in due installazioni di Millewin ottengano lo stesso codice identificativo.
All'atto della copia e riprescrizione di un accertamento, Millewin cerca il codice AC_CODE della tabella CART_ACCERT nel codice CO_TAB_ACC della tabella TAB_ACC; appena tova una corrispondenza copia la descriizione dell'accertamento contenuta in TAB_ACC senza fare alcun controllo di corrispondenza con la descrizione dell'esame gia' prescritto al paziente e contenuta in CART_ACCERT.
La soluzione sarebbe quella di rendere il piu' possibile univoco il codice CO_TAB_ACC per gli accertamenti inseriti dall'utente, o effettuare un controllo di corrispondenza tra il dato tabellare e quello che si sta riprescrivendo, e nella comparsa di un avviso nel caso si rilevino discordanze. Cosa che avevo gia' applicato nel mio programma dieci anni fa, prevedendo questo inconveniente, ma alla Dedalus avranno cose piu' importanti a cui pensare.

**madelbi** Sab 3 Mar 2012 - 20:02

Guido ha scritto:Prosegue la mia carrellata:

PROBLEMA CON IL SINCRO.

Probabilmente gli utenti piu' esperti di Millewin conosceranno questo inconveniente, che mi ha fatto tribolare un po', malgrado una consulenza chiesta via email alla dedalus.
Il problema si crea quando dopo aver creato un sincro.db (per es. in casa), lo si trasporta su un'altra postazione (per.es. studio) senza cancellare il sicro.db originale o senza disattivare l'abilitazione al RRS Locale nel PC di origine, in modo da non effettuare nessuna sincronizzazione ulteriore neanche per un attimo.
Se si rieffettua una sincronizzazione in casa, quando si ritrasferisce il sincro dello studio nella postazione di casa, non verranno trasferiti tutti i dati modificati e/o creati nello studio, ma solo quelli intermedi tra l'ultima sincronizzazione effettuata in studio e l'ultima effettuata in casa.
Come caso estremo se l'ultima sincronizzazione effettuata in casa e' posteriore all'ultima dello studio, anche solo consultando i dati di un unico paziente, viene trasferito solo quell'unico paziente dal Mille.db di casa al sincro dello studio, e nessun dato nella direzione opposta.
Possibile che alla Dedalus non abbiano ben messo in evidenza che la sincronizzazione nel Millewin di origine deve essere disabilitata permanentemente ?
La soluzione del problema a mio parere sarebbe molto semplice con un poco di programmazione aggiuntiva, o semplicemente scrivendolo nel manuale chiaramente.Ma evidentemente sono troppo occupati per fare cio'.

Io credo che la procedura di allestimento della SINCRO in Millewin - Milleutilità sia sufficientemente chiara. Mi è capitato alcune volte che il file sincro si sia corrotto e allora l'ho recuperato dalle postazioni su cui era integro e mi è capitato anche di doverlo ricreare ex-novo. Mi pare evidente che in questi casi tutti gli altri sincro vanno eliminati e non si può fare un miscuglio vecchi-nuovi... Se tu fai un sincro nuovo a casa, lo porti in studio e lo sincronizzi con il mille.db dello studio poi lo riporti a casa e lo risincronizzi con il mille.db di casa non perdi alcun dato. E' chiaro che eventuali sincro vecchi nello studio o da altre parti non vanno considerati

Guido Sab 3 Mar 2012 - 20:39

madelbi ha scritto: Io credo che la procedura di allestimento della SINCRO in Millewin - Milleutilità sia sufficientemente chiara. Mi è capitato alcune volte che il file sincro si sia corrotto e allora l'ho recuperato dalle postazioni su cui era integro e mi è capitato anche di doverlo ricreare ex-novo. Mi pare evidente che in questi casi tutti gli altri sincro vanno eliminati e non si può fare un miscuglio vecchi-nuovi... Se tu fai un sincro nuovo a casa, lo porti in studio e lo sincronizzi con il mille.db dello studio poi lo riporti a casa e lo risincronizzi con il mille.db di casa non perdi alcun dato. E' chiaro che eventuali sincro vecchi nello studio o da altre parti non vanno considerati

Grazie per la risposta.
Forse mi sono spiegato male. L'unico "errore" se cosi' si puo' chiamare, e che dopo la generazione del file sincro.db in casa, io lo copiavo nella chiavetta USB lo portavo in studio, ma lasciavo il vecchio sincro.db nel PC di casa libero di essere aggiornato dal Millewin di casa.
Quando riportavo il sincro.db dello studio in casa, cancellavo o rinominavo il sincro di casa o lo sovrascrivevo con quello proveniente dallo studio, e se nel frattempo non avevo mai lanciato Millewin a casa, la sincronizzazione tra i dati dello studio e il Mille.db di casa avveniva regolarmente nella sua interezza. Ma se avevo commesso l' "errore" di lanciare Millewin di casa con il suo sincro di casa attivo, gli unici dati che venivano trasferiti erano quelli compresi tra l'ultima sincronizzazione nello studio e quella effettuata in casa.
Evidentemente Millewin memorizza la date e l'ora dell'ultima sincronizzazione anche al di fuori del file sincro.db . Quando si avvia Millewin, quest'ultimo, per velocizzare le operazioni controlla quella data e legge solo i dati del file sincro.db che sono posteriori a quella data, e li confronta con i dati corrispondenti del file Mille.
Se la mia teoria e' giusta la soluzione sarebbe semplice ( e' questa la cosa che mi infastidisce) e lascerebbe l' ampia liberta' di mettere e togliere i files sincro come piu' gradito .
Notare che dopo aver esposto il problema alla dedalus dopo nove giorni non mi hanno piu' risposto.
Non so se sei d'accordo con la mia teoria

Guido

**Admin** Dom 4 Mar 2012 - 0:23

Uso RRS local per la sincronizzazione di due computer e non mi risulta di avere mai perso dei dati. Anche se a volte è capitato un problema con il trasferimento perché il pendrive non funzionava o perché l'avevo dimenticato o perché il file sincro era corrotto, non ho avuto problemi di perdita dei dati perché venivano recuperati alla successiva sincronizzazione. Mi par di capire che tu usi un sistema di sincronizzazione copiando manualmente il file sincro di volta in volta attraverso un pendrive da un computer all'altro, se ho capito bene è un sistema alquanto complicato. Per questo motivo ho reso automatico il procedimento in modo da renderlo più pratico ed efficiente. Il programma da me ideato si può scaricare dalla Mailing list utenti di Millewin al seguente link:

http://it.groups.yahoo.com/group/Mailing_list_utenti_Millewin/files/Sincronizzazione%20su%20HD.exe

Guido Dom 4 Mar 2012 - 0:51

Grazie, avevo visto la tua ottima utility. Non l'ho ancora provata, ma se ho ben capito nel tuo caso funziona tutto e bene perche' dopo l'ultima sincronizzazione il programma ( o forse e' uno script file, ripeto non l'ho provato) trasferisce il file sincro.db dall' HD alla penna USB (cancellandolo dall'HD) e quindi Millewin non puo' piu' sincronizzare se la penna USB viene trasferita su un altro PC e quindi non si dovrebbe verificare l'inconveniente da me segnalato.

Stavo riflettendo sulla questione, e potrei sospettare che il mio problema potrebbe essere determinato dalla prassi, penso consolidata, di effettuare la prima installazione e l'inserimento dei primi dati indispensabili su una postazione. Dopodiche' quando si crea la seconda postazione molti, tra cui il sottoscritto, copiano direttamente il file Mille.db nella nuova installazione, e quindi si potrebbe ipoteticamente vanificare una protezione per questo inconveneinte che potrebbe aver inserito la Dedalus: un codice univoco GUID generato al momento dellla installazione e memorizzato nel file Mlle.db. Quando viene generato il file sincro.db questo codice potrebbe essere copiato sul file sincro.db. Nel momento che il sincro.db viene trasferito su un'altra postazione l'altro Mille.db lo marcherebbe con il suo codice (diverso dal primo) e quindi riportando il sincro.db nella originaria postazione verrebbe riconosciuto non sincronizzato (anche se nel frattempo il precedente sincro.db e' rimasto nell'HD per tutto il periodo) e quindi partirebbe una sincronizzazione pressoche' completa, ovviamente solo dei records modificati.
Questo meccanismo di protezione potrebbe essere vaniificato dalla prassi di trasferire il file Mille.db, e quaindi i suoi codici GUID risulterebbero uguali in entrambi le postazioni.
E' solo un'ipotesi.
Ma cio' non toglie che con un sistema altrettanto semplice si potrebbe ottenere lo stesso scopo anche copiando il Mille.db da una postazione ad un'altra, e mi sembra strano che non ci abbiano pensato.

anpic Dom 4 Mar 2012 - 1:50

Guido ha scritto:
madelbi ha scritto: Io credo che la procedura di allestimento della SINCRO in Millewin - Milleutilità sia sufficientemente chiara. Mi è capitato alcune volte che il file sincro si sia corrotto e allora l'ho recuperato dalle postazioni su cui era integro e mi è capitato anche di doverlo ricreare ex-novo. Mi pare evidente che in questi casi tutti gli altri sincro vanno eliminati e non si può fare un miscuglio vecchi-nuovi... Se tu fai un sincro nuovo a casa, lo porti in studio e lo sincronizzi con il mille.db dello studio poi lo riporti a casa e lo risincronizzi con il mille.db di casa non perdi alcun dato. E' chiaro che eventuali sincro vecchi nello studio o da altre parti non vanno considerati

Grazie per la risposta.
Forse mi sono spiegato male. L'unico "errore" se cosi' si puo' chiamare, e che dopo la generazione del file sincro.db in casa, io lo copiavo nella chiavetta USB lo portavo in studio, ma lasciavo il vecchio sincro.db nel PC di casa libero di essere aggiornato dal Millewin di casa.
Quando riportavo il sincro.db dello studio in casa, cancellavo o rinominavo il sincro di casa o lo sovrascrivevo con quello proveniente dallo studio, e se nel frattempo non avevo mai lanciato Millewin a casa, la sincronizzazione tra i dati dello studio e il Mille.db di casa avveniva regolarmente nella sua interezza. Ma se avevo commesso l' "errore" di lanciare Millewin di casa con il suo sincro di casa attivo, gli unici dati che venivano trasferiti erano quelli compresi tra l'ultima sincronizzazione nello studio e quella effettuata in casa.
Evidentemente Millewin memorizza la date e l'ora dell'ultima sincronizzazione anche al di fuori del file sincro.db . Quando si avvia Millewin, quest'ultimo, per velocizzare le operazioni controlla quella data e legge solo i dati del file sincro.db che sono posteriori a quella data, e li confronta con i dati corrispondenti del file Mille.
Se la mia teoria e' giusta la soluzione sarebbe semplice ( e' questa la cosa che mi infastidisce) e lascerebbe l' ampia liberta' di mettere e togliere i files sincro come piu' gradito .
Notare che dopo aver esposto il problema alla dedalus dopo nove giorni non mi hanno piu' risposto.
Non so se sei d'accordo con la mia teoria

Guido

Il sincro (o meglio il file sincro) funziona come se fosse un pc che tu connetti in rete al al computer che stai usando in quel momento. Quando parte la sincronizzazione il sistema legge quando hai effettuato con quello specifico computer l'ultima sincronizzazione e aggiorna la pennina con i dati nuovi o variati trovati sul computer, e il computer con i dati nuovi o variati trovati sulla pennina. Dopodichè fa lo stesso con ogni altro computer su cui hai millewin, sempre riferendosi all'ultima sincronizzazione che hai effettuato su quella specifica macchina. E indifferente che tu lo faccia ogni giorno o una volta al mese, o se tu avendo più computer sincronizzi, che so, ogni giorno il n 1 e il n 2, e ogni mese il n 3 e il n 4: il sistema dopo un mese di mancata sincronizzazione non fa altro che cercare sulla pennina (file sincrodb) tutto ciò che per ogni singolo paziente è stato fatto in data successiva all'ultima sincronizzazione su quella specifica macchina, e viceversa, e allinea i dati; perciò se anche in linea teorica tu volessi sincronizzare venti pc una volta l'anno, a parte il fottio di tempo che ti ci vorrebbe, basta che in sequenza tu faccia il sincro su ogni singola macchina chiudendo il cerchio con la prima macchina sincronizzata (per portare anche su questa quanto di nuovo c'è sulla n20) e il gioco è fatto. Personalmente credo che il sincro sia forse uno dei punti di forza di MW. Unica avvertenza, ovvia, è di avere su tutte le macchine la stessa data e ore (cosa facile); dopodichè puoi anche lavorare in contemporanea (vera!) su tre macchine e con il sincro avrai sempre i dati perfettamente allineati.
Perciò non c'è bisogno di rinominare alcunchè: devi solo pensare alla pennina come un pc esterno che si incarica di "prendere e rilasciare" tutto ciò che è avvenuto di nuovo dall'ultima volta che è stato li. Se poi c'è il problema del tempo che ci vuole, le utility dei competentissimi colleghi di questo forum ti permettono di trasferire in locale il file sincro per accelerare la cosa e di ritrasferirlo sulla pennina a cose fatte, senza che tu possa dimenticartene.
Da anni sincronizzo cinque o sei macchine, alcune una tantum all'anno, e tutto funziona.

Mi sa che sono stato prolisso....

ciao
Anpic

Guido Dom 4 Mar 2012 - 10:56

Grazie Anpic per la tua risposta, ma
penso di essermi spiegato male.

In altre parole il mio “errore” se cosi' si puo' chiamare, e' stato quello di lasciare due file
sincro.db, (uno copia dell'altro) in giro, su due macchine diverse.

Potresti ottenere lo stesso “errore” se un giorno facessi una copia della tua chiavetta USB con il file
Sincro.db su un'altra chiavetta, per precauzione. Dopodiche' successivamente continuassi ad usare la prima chiavetta USB per le
sincronizzazioni.

Pero' un bel giorno potresti confonderti, ed usare la seconda chiave, pensando che contenga
l'ultima sincronizzazione. Ed a questo punto avverrebbe la frittata, perche' il file Mille.db che e' stato sincronizzato con la seconda
chiave non accetterebbe gli aggiornamenti presenti sulla prima chiave, quella contenente i dati piu' aggiornati, perche' la
riterrebbe obsoleta.

Questo inconveniente dovrebbe essere previsto da programmatori professionisti.

Ripeto, potrebbero scongiurare in parte l'inconveniente marcando ogni file Mille.db creato ex novo durante
ogni installazione con un numero identificativo diverso, ma questa precauzione verrebbe vanificata dalla prassi di copiare il file
Mille.db da una postazione all'altra.

Ma programmatori professionsiti dovrebbero prevedere anche questa possibilita' e vanificare questo
inconveniente con un piccolo sforzo di programmazione aggiuntiva che
avrei spiegato a loro, se mi avessero risposto. (se accettano
consigli dai dilettanti) Rolling Eyes

.

Guido Dom 4 Mar 2012 - 11:05

PROBLEMA CON CENTRALE DI CONTROLLO:

Non c'e' mai fine, e ogni volta mi
cascano le braccia. Anche qui non hanno saputo suggerirmi altra soluzione se non quella da me adottata e descritta piu' in basso.

Riporto il testo della email da me inviata alla Dedalus:

“in un PC a casa ho gia' da tempo(tre anni) installato il Sistema operativo win XP Pro sulla partizione H:\.
Notare che questa configurazione non mi ha creato quasi mai problemi, se non con qualche programma (di solito capita con qualche programma freeware) che si vuole installare automaticamente, senza alcuna possibilita' di scelta, su C:\.

Pertanto in fase di installazione di Millewin la directory SQLANY50 e' stata creata automaticamente su
H:\SQLANY50.
Il programma Millewin e' stato da me installato sulla partizione estesa/logica D:\, visibile da H:\ ma cio' penso non
costituisca un problema, in quanto in tutti i computer che ho Millewin e' installato su D:\ senza problemi.

Invece su questo PC lanciando alcuni comandi dalla Centrale di Controllo, quali "Verifica Database", il programma si arresta con
il messaggio di errore che non trova "c:\sqlany50\win32\dbvalid".
Evidentemente l'utility Centrale di Controllo e' stata concepita per essere installata obbligatoriamente su C:\.
C'e' un rimedio a questo problema?
(con un editor esadecimale ho sostituito nel file MilleCC.exe tutte le stringhe "C:\SQLANY50" con "H:\SQLANY50" ottenendo di far funzionare per es. il
comando Verifica Database, ma non mi sembra una soluzione raccomandabile, pertanto ho
ripristinato tutto come prima) “

**Admin** Dom 4 Mar 2012 - 20:10

Guido ha scritto:Grazie, avevo visto la tua ottima utility. Non l'ho ancora provata, ma se ho ben capito nel tuo caso funziona tutto e bene perche' dopo l'ultima sincronizzazione il programma ( o forse e' uno script file, ripeto non l'ho provato) trasferisce il file sincro.db dall' HD alla penna USB (cancellandolo dall'HD) e quindi Millewin non puo' piu' sincronizzare se la penna USB viene trasferita su un altro PC e quindi non si dovrebbe verificare l'inconveniente da me segnalato.

Stavo riflettendo sulla questione, e potrei sospettare che il mio problema potrebbe essere determinato dalla prassi, penso consolidata, di effettuare la prima installazione e l'inserimento dei primi dati indispensabili su una postazione. Dopodiche' quando si crea la seconda postazione molti, tra cui il sottoscritto, copiano direttamente il file Mille.db nella nuova installazione, e quindi si potrebbe ipoteticamente vanificare una protezione per questo inconveneinte che potrebbe aver inserito la Dedalus: un codice univoco GUID generato al momento dellla installazione e memorizzato nel file Mlle.db. Quando viene generato il file sincro.db questo codice potrebbe essere copiato sul file sincro.db. Nel momento che il sincro.db viene trasferito su un'altra postazione l'altro Mille.db lo marcherebbe con il suo codice (diverso dal primo) e quindi riportando il sincro.db nella originaria postazione verrebbe riconosciuto non sincronizzato (anche se nel frattempo il precedente sincro.db e' rimasto nell'HD per tutto il periodo) e quindi partirebbe una sincronizzazione pressoche' completa, ovviamente solo dei records modificati.
Questo meccanismo di protezione potrebbe essere vaniificato dalla prassi di trasferire il file Mille.db, e quaindi i suoi codici GUID risulterebbero uguali in entrambi le postazioni.
E' solo un'ipotesi.
Ma cio' non toglie che con un sistema altrettanto semplice si potrebbe ottenere lo stesso scopo anche copiando il Mille.db da una postazione ad un'altra, e mi sembra strano che non ci abbiano pensato.

Il mio programma è un semplice file batch che copia automaticamente all'avvio di millewin il file sincro.db dalla penna ad una cartella in millewin ed alla chiusura nel senso inverso. Nello stesso tempo, sia sulla penna che sul computer vengono generati 2 file sincro.old (cioè 2 sincro.db precedenti all'ultimo trasferimento da usare, rinominandoli in sincro.db, in caso di problemi). Inoltre sincronizza automaticamente la cartella "Immagini" che contiene gli allegati, ed altre due cartelle che possono essere fatture e certificati (o altro se si preferisce).

Nel trasferimento di sincro.db non avviene alcuna cancellazione di file, ma solo la copia sovrascrivendo sempre il file omonimo, quindi non si ha mai perdita di dati.

Quando si trasferisce millewin da un computer ad un altro SI DEVE trasferire il file mille.db, così si è sicuri dell'uguaglianza dei dati, e poi usando RRS locale per la successiva sincronizzazione non si perderà mai alcun dato, anche se capita di lavorare indipendentemente su ciascun computer e poi si decide di effettuare la sincronizzazione successivamente. E' evidente che è consigliabile sincronizzare tutti i giorni, ma se per qualche motivo si dovesse saltare non succede niente, tutto si recupera alla prima sincronizzazione successiva.

Al di fuori dell'installazione di millewin su un altro computer, non si deve MAI usare il trasferimento del file mille.db come alternativa alla sincronizzazione, perché si rischia seriamente di perdere dati e di non poterli più recuperare in alcun modo.

Guido Dom 4 Mar 2012 - 23:55

Admin ha scritto: Inoltre sincronizza automaticamente la cartella "Immagini" che contiene gli allegati, ed altre due cartelle che possono essere fatture e certificati (o altro se si preferisce).

Non mi importa per le fatture che faccio ancora a mano, ma non mi dire che NON SINCRONIZZA I CERTIFICATI RTF ? Evil or Very Mad

Se e' cosi' ci sarebbe da diglierne quattro alla Dedalus, perche' queste cose LE DEVONO SCRIVERE SUL MANUALE !!!

Nel trasferimento di sincro.db non avviene alcuna cancellazione di file, ma solo la copia sovrascrivendo sempre il file omonimo, quindi non si ha mai perdita di dati.

Aspetta, aspetta: vuoi dire che il tuo programma sovrascrive il file omonimo sulla penna USB o sovrascrive il file omonimo sull' HD lasciato alla fine della sincronizzazione precedente ? E quindi, se quest'ultima condizione e' vera, anche in assenza della penna USB si puo' lanciare Millewin con la sincronizzazione su HD attiva ? Shocked

Al di fuori dell'installazione di millewin su un altro computer, non si deve MAI usare il trasferimento del file mille.db come alternativa alla sincronizzazione, perché si rischia seriamente di perdere dati e di non poterli più recuperare in alcun modo.

Questa affermazione mi sorprende notevolmente, perche' e' una prassi che adotto abitualmente. Perche' si dovrebbe verificare cio' ?
Grazie per il momento, gradirei se mi chiarissi questo punto.

PS: Ho visto il tuo programma per la sincronizzazione su HD, c'e' molto lavoro dietro . Appena avro' un po' di tempo lo provero'

anpic Lun 5 Mar 2012 - 0:15

Guido ha scritto:
Admin ha scritto: Inoltre sincronizza automaticamente la cartella "Immagini" che contiene gli allegati, ed altre due cartelle che possono essere fatture e certificati (o altro se si preferisce).

Non mi importa per le fatture che faccio ancora a mano, ma non mi dire che NON SINCRONIZZA I CERTIFICATI RTF ?
Se e' cosi' ci sarebbe da diglierne quattro alla Dedalus, perche' queste cose LE DEVONO SCRIVERE SUL MANUALE !!!

Nel trasferimento di sincro.db non avviene alcuna cancellazione di file, ma solo la copia sovrascrivendo sempre il file omonimo, quindi non si ha mai perdita di dati.

Aspetta, aspetta: vuoi dire che il tuo programma sovrascrive il file omonimo sulla penna USB o sovrascrive il file omonimo sull' HD lasciato alla fine della sincronizzazione precedente ? E quindi, se quest'ultima condizione e' vera, anche in assenza della penna USB si puo' lanciare Millewin con la sincronizzazione su HD attiva ?

Al di fuori dell'installazione di millewin su un altro computer, non si deve MAI usare il trasferimento del file mille.db come alternativa alla sincronizzazione, perché si rischia seriamente di perdere dati e di non poterli più recuperare in alcun modo.

Questa affermazione mi sorprende notevolmente, perche' e' una prassi che adotto abitualmente. Perche' si dovrebbe verificare cio' ?
Grazie per il momento, gradirei se mi chiarissi questo punto.

PS: Ho visto il tuo programma per la sincronizzazione su HD, c'e' molto lavoro dietro . Appena avro' un po' di tempo lo provero'

Non devi mai copiare il file milledb da un pc all'altro, ma solo usare sincro, perchè se nel pc n1 all'ora x lavori sui paz. A e B, e successivamente sul pc n2 lavori sul paz C e D, quando da pc 1 copi il milledb sul PC 2 non fai altro che portare quanto hai fatto sul pc 1 sul 2, ma perdi quanto hai fatto sul 2, perchè sovrascrivi il database. Il sincro, invece, fa il "merge" di quanto hai fatto sull'uno e sull'altro tenendo conto dei dati più recenti (dal che ovviamente discende che devi avere la stessa ora). Tutto ciò simulando sul file sincro un terzo file milledb che prende/cede al pc con cui sincronizza i dati variati dall'ultima "visita".
Mi sa che devi prima acquisire questo concetto per non perdere dati. E tutto ciò è molto più pratico di fare copia/incolla, perchè mi permette, in teoria, di lavorare con due PC accesi davanti a me e di prescrivere allo stesso paziente un farmaco su un pc e contemporaneamente prescriverne un altro sull'altro pc: dopo il sincro avrò le due prescrizioni su tutte e due le macchine.

riciao

Anpic

Guido Lun 5 Mar 2012 - 1:16

Grazie Anpic per la spiegazione, ma sospetto che Blasio volesse dire qualcos'altro, anche perche' avra' intuito che conosco benissimo il concetto di sincronizzazione Cool

Grazie e buonanotte

**Admin** Lun 5 Mar 2012 - 13:01

Guido ha scritto:
Admin ha scritto: Inoltre sincronizza automaticamente la cartella "Immagini" che contiene gli allegati, ed altre due cartelle che possono essere fatture e certificati (o altro se si preferisce).

Non mi importa per le fatture che faccio ancora a mano, ma non mi dire che NON SINCRONIZZA I CERTIFICATI RTF ?
Se e' cosi' ci sarebbe da diglierne quattro alla Dedalus, perche' queste cose LE DEVONO SCRIVERE SUL MANUALE !!!

Certo che sincronizza i certificati RTF, ma mi riferivo all'archiviazione dei certificati di malattia on line fatti dal sito SistemaTs o con altri programmi appositi.

Guido ha scritto:
Admin ha scritto:

Nel trasferimento di sincro.db non avviene alcuna cancellazione di file, ma solo la copia sovrascrivendo sempre il file omonimo, quindi non si ha mai perdita di dati.
Aspetta, aspetta: vuoi dire che il tuo programma sovrascrive il file omonimo sulla penna USB o sovrascrive il file omonimo sull' HD lasciato alla fine della sincronizzazione precedente ? E quindi, se quest'ultima condizione e' vera, anche in assenza della penna USB si puo' lanciare Millewin con la sincronizzazione su HD attiva ?

All'apertura di millewin sovrascrive il sincro.db sul HD, alla chiusura quello sulla penna. Quindi un sincro aggiornato resta anche sull' HD che continua a sincronizzare. In tal modo, si può continuare a lavorare sullo stesso computer anche senza penna inserita, basta metterla prima dell'ultima chiusura di millewin ed il file sincro.db aggiornato vine trasferito sulla penna.

Guido ha scritto:
Admin ha scritto:

Al di fuori dell'installazione di millewin su un altro computer, non si deve MAI usare il trasferimento del file mille.db come alternativa alla sincronizzazione, perché si rischia seriamente di perdere dati e di non poterli più recuperare in alcun modo.

Questa affermazione mi sorprende notevolmente, perche' e' una prassi che adotto abitualmente. Perche' si dovrebbe verificare cio' ?
Grazie per il momento, gradirei se mi chiarissi questo punto.

PS: Ho visto il tuo programma per la sincronizzazione su HD, c'e' molto lavoro dietro . Appena avro' un po' di tempo lo provero'

Concordo con anpic, il sistematico trasferimento di mille.db inevitabilmente ti porterà a perdere dati. Metti che vai allo studio e la penna non funziona, che fai? Torni a casa a fare un'altra copia di mille.db ?

Guido Mar 6 Mar 2012 - 0:03

Admin ha scritto:
Certo che sincronizza i certificati RTF, ma mi riferivo all'archiviazione dei certificati di malattia on line fatti dal sito SistemaTs o con altri programmi appositi.

Ah, tiro un sospiro di sollievo

All'apertura di millewin sovrascrive il sincro.db sul HD, alla chiusura quello sulla penna. Quindi un sincro aggiornato resta anche sull' HD che continua a sincronizzare. In tal modo, si può continuare a lavorare sullo stesso computer anche senza penna inserita, basta metterla prima dell'ultima chiusura di millewin ed il file sincro.db aggiornato vine trasferito sulla penna.

Qui andiamo male, nel senso che se ho ben capito, ti trovi nella situazione che a me crea problemi. Quindi vorrei capire se e'un problema solo mio, o se il sistema di Sincro di Millewin che crea questo inconveniente che mi sta facendo tribolare.
Per spiegarlo in altre parole descrivo la situazione che si e' creata la settimana scorsa: avevo un sincro su HD nello studio, che veniva sincronizzato continuamente, ed un altro sincro sull'HD a casa, che veniva anch'esso aggiornato ad ogni avvio di Millewin.
Solo che quello dello studio viene aggiornato tutti i giorni, ovviamente, mentre quello in casa solo saltuariamente ad ogni avvio di Millewin.
La settimana scorsa ho avviato il Millewin di casa solo il Giovedi', per fare la prova che mi ripromettevo di fare Venerdi' sera.
Venerdi' sera alla fine dell'ambulatorio ho preso il sincro dello studio, l'ho portato a casa, ho rinominato il sincro di casa e piazzato il sincro dello studio al suo posto.
Ho avviato Millewin e dopo l'avvio della prima sincronizzazione ho controllato nella icona RRS LOcal sulla barra delle applicazioni la lista dei pazienti inviati e ricevuti dal sincro: ricevuti dal sincro solo quell' unico paziente che avevo modificato il Giovedi'; inviati SOLO i pazienti che avevo visto in ambulatorio il Venerdi' e non quelli visti negli altri giorni della settimana Shocked

Sembra che, in altre parole, Millewin di casa abbia memorizzato da qualche parte la data dell'ultima sincronizzazione effettuata a casa (Giovedi') e si sia preoccupato di trasferire dal sincro solo i pazienti che sono risultati modificati posteriormente a quella data, senza accorgersi, quindi, che il file Sincro.db era cambiato !

Quindi se anche con il tuo metodo Millewin dovesse comportarsi allo stesso modo, sarebbe un bel pasticcio (cosa che evidentemente non succede, altrimenti te ne saresti accorto) : supponendo che il Mercoledi' tu non porti la chiavetta USB in studio, per tutto il Mercoledi' Millewin sincronizzerebbe sul sincro dell'HD; il Giovedi' tu porti la chiavetta nello studio, il tuo programma mette il sincro della chiavetta al posto del sincro.db dell'HD, parte Millewin e la sincronizzazione , ma comincerebbero ad essere trasferiti sul sincro solo i pazienti modificati il Giovedi', e non quelli del Mercoledi', perche' Millewin considerebbe quelli del Mercoledi' gia' trasferiti sul sincro.db !

Ora c'e' da chiedersi perche' a me capiti cio' Sad

Concordo con anpic, il sistematico trasferimento di mille.db inevitabilmente ti porterà a perdere dati. Metti che vai allo studio e la penna non funziona, che fai? Torni a casa a fare un'altra copia di mille.db ?

Ma queste problematiche le conosco ! Sono informatizzato dal 1992 ! Very Happy

Io pensanvo che volessi accennare a qualche inconveniente misterioso nel tarsferimento del Mille.db !
Se ti viene qualche idea riguardo al mio problema fammi sapere !
Ciao e grazie
Guido

**Admin** Mar 6 Mar 2012 - 10:21

Guido ha scritto:
Admin ha scritto:

All'apertura di millewin sovrascrive il sincro.db sul HD, alla chiusura quello sulla penna. Quindi un sincro aggiornato resta anche sull' HD che continua a sincronizzare. In tal modo, si può continuare a lavorare sullo stesso computer anche senza penna inserita, basta metterla prima dell'ultima chiusura di millewin ed il file sincro.db aggiornato vine trasferito sulla penna.

Qui andiamo male, nel senso che se ho ben capito, ti trovi nella situazione che a me crea problemi. Quindi vorrei capire se e'un problema solo mio, o se il sistema di Sincro di Millewin che crea questo inconveniente che mi sta facendo tribolare.
................................................

Ciao e grazie
Guido

Ti consiglio di tenere un SOLO sincro.db sul pendrive e di indirizzare RRS locale solo su quel file per ciascun computer su cui usi millewin, e vedrai che il problema sarà risolto.

Guido Mar 6 Mar 2012 - 17:32

Admin ha scritto:

Ti consiglio di tenere un SOLO sincro.db sul pendrive e di indirizzare RRS locale solo su quel file per ciascun computer su cui usi millewin, e vedrai che il problema sarà risolto.

Bene, facendo cosi' so gia' che non ci sarebbero problemi, perche' gia' provato e perche' questa procedura segue alla lettera quanto indicato sul manuale. Ora mi chiedo perche' alla Dedalus non mi abbiano risposto allo stesso modo quando ho esposto il mio problema, dove ho indicato chiaramente che lasciavo il file Sincro sull'HD libero di essere aggiornato, oltre che sulla pennetta.
Ma poi mi chiedo perche' con il tuo programma tutto funzioni anche lasciando il Sincro sull'HD, nell'attesa di avere il tempo di provarlo, cosi' mi si chiariranno, forse, le idee .

Grazie di nuovo !
Guido

pvelona Mar 6 Mar 2012 - 19:29

Caro Blasio,

complice l'influenza e l'ennesima usura del pendrive che uso per la sincronizzazione RRSlocal con la nota difficoltà a reperire pendrive veloci, ti chiedo alcune informazioni sul tuo programma di sincronizzazione che ho già visto sulla ML da tempo e che, per mancanza di tempo, non ho mai avuto modo di installare. Scusami per la prolissità. Preciso che lavoro su 3 postazioni (1 a casa + 2 studi).

1) E' possibile installare il tuo programma su una sola postazione (quella di casa) e impratichirmi nell'attesa di installarlo anche sulle altre postazioni?

2) Considerando che ho sempre tenuto sincronizzate correttamente e senza perdita di dati tutte le postazioni con RRS local, cominciando a usare il tuo programma dopo averlo installato, in un secondo momento, sul pc di uno studio, a tuo parere dovrebbe comparirmi l'avviso "preparare il sincro per il secondo studio"? Se sì, l'operazione di sincronizzazione sarà molto lunga?

3) In uno dei due studi, il principale, utilizzo una rete locale, in cui il mio pc fisso è il server e il portatile della segretaria funge da client. Immagino di non dover modificare il pc della segretaria (che peraltro monta l'odiatissimo - da me - Win7) in quanto client.

Ma poichè mi piace tenerlo aggiornato per un eventuale utilizzo stand alone di emergenza da parte mia (e quindi periodicamente lo sincronizzo con RRSlocal), posso installare il tuo programma per sincronizzare periodicamente anche quel pc? Se sì, usandolo, come d'abitudine, in modalità client, la segretaria deve entrare cliccando su Millewin. exe (come credo sia giusto) o su Mille.start?

4) E infine (scusa la domanda inopportuna ma ... necessaria), nel malaugurato caso non dovessi trovarmi bene, o dovessero insorgere problemi, è possibile (e come?) disinstallare il programma e tornare allo stato quo ante?

Grazie delle risposte che mi darai e soprattutto della pazienza che avrai se risponderai a tutti i miei quesiti.

**Admin** Mar 6 Mar 2012 - 20:34

Guido ha scritto:
Admin ha scritto:

Ti consiglio di tenere un SOLO sincro.db sul pendrive e di indirizzare RRS locale solo su quel file per ciascun computer su cui usi millewin, e vedrai che il problema sarà risolto.

Bene, facendo cosi' so gia' che non ci sarebbero problemi, perche' gia' provato e perche' questa procedura segue alla lettera quanto indicato sul manuale. Ora mi chiedo perche' alla Dedalus non mi abbiano risposto allo stesso modo quando ho esposto il mio problema, dove ho indicato chiaramente che lasciavo il file Sincro sull'HD libero di essere aggiornato, oltre che sulla pennetta.
Ma poi mi chiedo perche' con il tuo programma tutto funzioni anche lasciando il Sincro sull'HD, nell'attesa di avere il tempo di provarlo, cosi' mi si chiariranno, forse, le idee .

Grazie di nuovo !
Guido

Il discorso è che il sincro.db che viene trasportato da un computer ad un altro deve essere sempre lo stesso, non è possibile incrociarne due diversi. Con il mio programma è vero che il sincro rimane su tutti i computer e continua a sincronizzare, ma quando inserisci la penna ed apri Mille_start il sincro della penna va a sovrascrivere quello del computer, annullando di fatto le ultime variazioni eventualmente effettuate senza l'uso della penna.

Credo comunque che sia più semplice usare il programma piuttosto che spiegare nei dettagli il funzionamento.

**Admin** Mar 6 Mar 2012 - 20:51

Caro Blasio,

complice l'influenza e l'ennesima usura del pendrive che uso per la sincronizzazione RRSlocal con la nota difficoltà a reperire pendrive veloci, ti chiedo alcune informazioni sul tuo programma di sincronizzazione che ho già visto sulla ML da tempo e che, per mancanza di tempo, non ho mai avuto modo di installare. Scusami per la prolissità. Preciso che lavoro su 3 postazioni (1 a casa + 2 studi).

1) E' possibile installare il tuo programma su una sola postazione (quella di casa) e impratichirmi nell'attesa di installarlo anche sulle altre postazioni?

- Si

2) Considerando che ho sempre tenuto sincronizzate correttamente e senza perdita di dati tutte le postazioni con RRS local, cominciando a usare il tuo programma dopo averlo installato, in un secondo momento, sul pc di uno studio, a tuo parere dovrebbe comparirmi l'avviso "preparare il sincro per il secondo studio"? Se sì, l'operazione di sincronizzazione sarà molto lunga?

- No, è subito operativo

3) In uno dei due studi, il principale, utilizzo una rete locale, in cui il mio pc fisso è il server e il portatile della segretaria funge da client. Immagino di non dover modificare il pc della segretaria (che peraltro monta l'odiatissimo - da me - Win7) in quanto client.

- Nessuna modifica, il programma è indipendente dal sistema operativo

Ma poichè mi piace tenerlo aggiornato per un eventuale utilizzo stand alone di emergenza da parte mia (e quindi periodicamente lo sincronizzo con RRSlocal), posso installare il tuo programma per sincronizzare periodicamente anche quel pc? Se sì, usandolo, come d'abitudine, in modalità client, la segretaria deve entrare cliccando su Millewin. exe (come credo sia giusto) o su Mille.start?

- cliccando su Millewin.exe si apre millewin ma non avviene la sincronizzazione con gli altri PC, con Mille_Start si.

4) E infine (scusa la domanda inopportuna ma ... necessaria), nel malaugurato caso non dovessi trovarmi bene, o dovessero insorgere problemi, è possibile (e come?) disinstallare il programma e tornare allo stato quo ante?

- Basta reindirizzare in centrale di controllo RRS locale sul sincro della penna.

Grazie delle risposte che mi darai e soprattutto della pazienza che avrai se risponderai a tutti i miei quesiti

- Prego

pvelona Mar 6 Mar 2012 - 20:59

Admin ha scritto:Caro Blasio,

complice l'influenza e l'ennesima usura del pendrive che uso per la sincronizzazione RRSlocal con la nota difficoltà a reperire pendrive veloci, ti chiedo alcune informazioni sul tuo programma di sincronizzazione che ho già visto sulla ML da tempo e che, per mancanza di tempo, non ho mai avuto modo di installare. Scusami per la prolissità. Preciso che lavoro su 3 postazioni (1 a casa + 2 studi).

1) E' possibile installare il tuo programma su una sola postazione (quella di casa) e impratichirmi nell'attesa di installarlo anche sulle altre postazioni?

- Si

2) Considerando che ho sempre tenuto sincronizzate correttamente e senza perdita di dati tutte le postazioni con RRS local, cominciando a usare il tuo programma dopo averlo installato, in un secondo momento, sul pc di uno studio, a tuo parere dovrebbe comparirmi l'avviso "preparare il sincro per il secondo studio"? Se sì, l'operazione di sincronizzazione sarà molto lunga?

- No, è subito operativo

3) In uno dei due studi, il principale, utilizzo una rete locale, in cui il mio pc fisso è il server e il portatile della segretaria funge da client. Immagino di non dover modificare il pc della segretaria (che peraltro monta l'odiatissimo - da me - Win7) in quanto client.

- Nessuna modifica, il programma è indipendente dal sistema operativo

Ma poichè mi piace tenerlo aggiornato per un eventuale utilizzo stand alone di emergenza da parte mia (e quindi periodicamente lo sincronizzo con RRSlocal), posso installare il tuo programma per sincronizzare periodicamente anche quel pc? Se sì, usandolo, come d'abitudine, in modalità client, la segretaria deve entrare cliccando su Millewin. exe (come credo sia giusto) o su Mille.start?

- cliccando su Millewin.exe si apre millewin ma non avviene la sincronizzazione con gli altri PC, con Mille_Start si.

4) E infine (scusa la domanda inopportuna ma ... necessaria), nel malaugurato caso non dovessi trovarmi bene, o dovessero insorgere problemi, è possibile (e come?) disinstallare il programma e tornare allo stato quo ante?

- Basta reindirizzare in centrale di controllo RRS locale sul sincro della penna.

Grazie delle risposte che mi darai e soprattutto della pazienza che avrai se risponderai a tutti i miei quesiti

- Prego
.

Sempre grazie per le risposte precise e dettagliatissime.

Sul punto 3: se la segretaria lavora come client è il mio pc (server) che deve sincronizzarsi, non il suo, quindi lei può entrare nel programma con Millewin.exe e non compromette sincronizzazioni future. Se invece entra con Millle.start può sincronizzare qualcosa essendo un client?

**Admin** Mar 6 Mar 2012 - 21:35

pvelona ha scritto:

.....................
Sul punto 3: se la segretaria lavora come client è il mio pc (server) che deve sincronizzarsi, non il suo, quindi lei può entrare nel programma con Millewin.exe e non compromette sincronizzazioni future. Se invece entra con Millle.start può sincronizzare qualcosa essendo un client?

- In questo caso non serve la sincronizzazione sul client, pertanto è inutile installare il programma su quel computer, è sufficiente sincronizzare il server su cui risiede il database.

Contenuto sponsorizzato

Alcuni grossi problemi di MW

Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW

Re: Alcuni grossi problemi di MW