Pagina 1 di 2 1 2 ultimoultimo
Visualizzazione dei risultati da 1 a 10 su 15

Discussione: webservice

  1. #1
    Utente di HTML.it
    Registrato dal
    Jun 2003
    Messaggi
    4,826

    webservice

    ho creato un applicazione distribuita nel seguente modo:
    Ho n utenti che accedono al web service , ciascuno di essi ha una copia del database in remoto .
    Ho usato campi contatore per la chiave primaria id .
    Quando l'utente si collega , scarica la parte del database in remoto che gli manca tramite l'id massimo della tabella in locale(carica tutti i record della tabella in remoto dove id > max(id) della tabella in locale.
    Cosa succede se un utente modifica o cancella un record ? come faccio a notificare agli altri utenti che quell'id va ricaricato (se è stato modificato) o cancellato ?
    es: sono l'utente 1 mi connetto e cancello il record 33 sia sul remoto che sul locale;sono l'utente2 mi connetto e carico i record dal 55 in poi (55 è l'id massimo di quell tabella)
    non cancello il record sul database in locale , quindi continua ad apparirmi come se ci fosse!
    Ho pensato di usare la data (da anno a millisecondi) trasformata in numerico per l'id di modo che l'utente carichi tutti i record successivi all' istante dell'ultima connessione ; è una scelta giusta?se si come fare a sincronizzare la data col server?
    Se non mi sono spiegato bene ditelo,
    Grazie in anticipo.
    Il mio problema principale è quello di sincronizzare la data col server in quanto il server potrebbe avere o sicuramente ha una data diversa dal client(soprattutto millesimi o secondi o minuti)

  2. #2
    Se ho capito:
    Dovresti tenere traccia degtli aggiornamenti fatti dagli utenti, poi passerai i record con la data aggiornamento del record maggiore di quella dell'ultimo aggiornamento dell'utente. La data la valorizzerai sempre partendo dal server e quindi non dovresti avere problemi.

  3. #3
    Utente di HTML.it
    Registrato dal
    Jun 2003
    Messaggi
    4,826
    devo cioè creare un webmethod che mi restituisca la data in modo da avere la data sul client=a quella del server?

  4. #4
    No quello che pensavo era un po diverso, anche perche la osa dell'id maggiore dell'ultimo importato non ti permetterebbe di importare record vecchi modificati.
    In tutte le tabelle che possono essere scaricate e modificate aggiungi un campo [DataModifica], che indica la data in cui è stato effettuato l'ultimo aggiornamento, e un campo [Deleted] che indica che il campo è stato eliminato

    Aggiungi una tabella [Aggiornamenti] dove tenere traccia degli aggiornamenti fatti dagli utenti:
    idUtente intero
    DataUltimoAggiornamento Date
    - Quando un'utente cerca gli ultimi aggiornamenti gli passi tutti i record con [Tabella].[DataModifica]>[Aggiornamenti].[DataUltimoAggiornamento] e in un secondo momento gli puoi passare, con lo stesso filtro i record da eliminare (quindi con il campo [Deleted] checcato. Una volta terminata l'operazione aggiorni il campo [DataUltimoAggiornamento] con la data corrente
    - Quando un'utente scarica i dati li aggiorni o li aggiungi sempre utilizzando l'id univoco, valorizzando [DataModifica] sempre con la data odierna

    Nota che tutte le query saranno eseguite sul server, non avendo qundi nessun problema di sincronizzare le date, che pio anche evitare di passare nelle tabelle salvate in locale dai singoli utenti.

    Quello che mancherebbe è un controllo per evitare che due utenti modifichino lo stesso record, ma li forse diventerebbe un po più complicato (un utente dovrebbe bloccare un record, metti con un campo booleano sulla tabella, prima di modificarlo, e poi sbloccarlo quando viene ripassato al server)

    Spero di essermi capito :bubu:

  5. #5
    Utente di HTML.it
    Registrato dal
    Jun 2003
    Messaggi
    4,826
    Sei stato molto esaustivo e gentile.
    Ultima cosa : invece di aggiungere un valore per il record bloccato si puo' usare la concorrenza ottimistica?

  6. #6
    Originariamente inviato da giuseppe500
    Sei stato molto esaustivo e gentile.
    Ultima cosa : invece di aggiungere un valore per il record bloccato si puo' usare la concorrenza ottimistica?
    No, quello andrebbe bene se si usa un database solo (mentre un utente modifica il record ,è bloccato) ma essendo su database diversi non potrebbe funzionare, perchè sul database server nessuno sta modificando record mentre li stà modificando sul suo database in locale.


  7. #7
    Utente di HTML.it
    Registrato dal
    Jun 2003
    Messaggi
    4,826
    Scusa ma non ho capito bene;
    Se la data di sistema per gli utenti è diversa non si va incontro a casini?

  8. #8
    Originariamente inviato da giuseppe500
    Scusa ma non ho capito bene;
    Se la data di sistema per gli utenti è diversa non si va incontro a casini?
    Ma in realtà la data degli utenti non la leggi mai, tutte le query sono eseguite sul server, e quindi la data utilizzata è sempre quella del server...

  9. #9
    Utente di HTML.it
    Registrato dal
    Jun 2003
    Messaggi
    4,826
    Aggiungi una tabella [Aggiornamenti] dove tenere traccia degli aggiornamenti fatti dagli utenti:
    idUtente intero
    DataUltimoAggiornamento Date
    - Quando un'utente cerca gli ultimi aggiornamenti gli passi tutti i record con [Tabella].[DataModifica]>[Aggiornamenti].[DataUltimoAggiornamento] e in un secondo momento gli puoi passare, con lo stesso filtro i record da eliminare (quindi con il campo [Deleted] checcato. Una volta terminata l'operazione aggiorni il campo [DataUltimoAggiornamento] con la data corrente
    - Quando un'utente scarica i dati li aggiorni o li aggiungi sempre utilizzando l'id univoco, valorizzando [DataModifica] sempre con la data odierna
    vuoi dire che è il server ad aggiornare o inserire datamodifica?
    se si , questo non appesantisce il server?

  10. #10
    Non, non è appesantito, la data la valorizzi con la stessa query con cui aggiorni o aggiungi record, con la differenza che mentre gli altri campi li prenderai dal dataset che ti passa l'utente, il campo data lo passi fisso con la data di sistema

Permessi di invio

  • Non puoi inserire discussioni
  • Non puoi inserire repliche
  • Non puoi inserire allegati
  • Non puoi modificare i tuoi messaggi
  •  
Powered by vBulletin® Version 4.2.1
Copyright © 2025 vBulletin Solutions, Inc. All rights reserved.