Vai al contenuto
PLC Forum


Movicon - Sql


dwayne

Messaggi consigliati


Ciao Dwayne, scrivi pure cosa ti serve sapere. Io e altri utenti usiamo Movicon da tempo, e spesso (quasi sempre) capita di utilizzarlo con SQLServer, conoscendo le limitazioni di Access ;)

Ciaoo :)

Link al commento
Condividi su altri siti

Ok. Sql lo conosco veramente poco.

Io ho sempre usato Access, con datalogger che registrano ogni 30sec., mensilmente faccio un backup (copia del file .mdb rinominata con il nome del mese) e svuoto il database in uso, così da ripartire con il mese nuovo con il db vuoto.

Poi dall'oggetto Trend, se voglio ripescare i dati vecchi (del mese scorso o di 5 anni fa), uso il pulsante "Backup", vado cercare il file che mi serve e carico i dati.

Sql non funziona così (intendo a file) e non è possibile, dopo aver fatto un backup, fare un'operazione di ripristino senza chiudere Movicon. Operazione che tra l'altro andrebbe a sostituirsi ai dati correnti.

Sicuramente avrò detto delle bestiate, spero, però, di essermi spiegato.

In sostanza, il database, per quanto possa essere capiente, prima o poi si riempirà quindi, voi come utilizzate Sql server?

ciao

Link al commento
Condividi su altri siti

Ciao Dwayne, una risposta secca alla tua domanda non esiste, o meglio, la risposta sarebbe: dipende da quello che vuole il Cliente e che versione di SQL si utilizza.

Infatti la situazione sarà diversa utilizzando SQL Server con licenza, dagli SQL in versione Express (che limitano le dimensioni massime del DB).

Dipende poi se il Cliente vuole fare un archivio di backup oppure no.

SQL in effetti non è come Access, il backup lo devi fare con determinati comandi (e puoi farlo in RUN), mentre il Restore lo devi fare per forza senza alcuna connessione aperta verso il DB (altrimenti SQL si arrabbia).

Se devi utilizzare il Trend, e devi poter poi andare a ripescare un backup salvato indietro nel tempo, potresti ricorrere ad una soluzione mista SQL e Access.

I datalogger li potresti configurare per salvare i dati su SQL (impostando un giusto tempo di Durata massima dati a seconda della versione SQL che hai, con licenza - quindi dimensioni enormi di DB - o versione Express - direi 4 o 8 GB di dati per singolo DB).

Dopodichè, quando necessario, potresti lanciare il backup del Datalogger: se ti serve avere un backup in SQL lo fai (eventualmente con comandi Sql da file Batch), in più, potresti crearti un backup in formato MS Access tramite uno scritp in visual basic che, utilizzando gli ADO di Microsoft, ti crea un DB Access e ti copia i dati dalla tabella in SQL su quella in Access.

Questo ti servirebbe per poter poi andare a pescare il backup del file Access e visualizzarlo all'interno del Trend.

Il Trend, infatti, come formato DB dei backup interpreta solo il file Access.

A questo punto hai la situazione più completa che possa servirti:

- Backup in SQL per eventuali necessità di Restore;

- Backup in Access per poter visualizzare i dati nel Trend.

Ovviamente tutto questo dipende dal PC su cui monti il progetto e dalla sua capacità (intendo l'HDD).

Cerca tra gli esempi che ci sono sul sito di progea nell'area support...probabilmente troverai già qualcosa di fatto o che comunque ti può aiutare come base da cui partire a sviluppare le funzioni di cui hai bisogno.

Ciaoo :)

Link al commento
Condividi su altri siti

  • 2 weeks later...

Ciao Tony, l'esempio sul sito l'ho guardato e va bene.

Quindi, aldilà della versione di Sql (Express o completa) per tornare a vedere dati vecchi sul Trend devo comunque utilizzare Access, tu (e gli altri che hanno già provato) lo usi così.

Pensavo che supportando SqlServer (oltre a mysql etc...) riuscisse a gestire i dati anche nel trend, così invece non resta un po' "zoppo"?

ciao

Link al commento
Condividi su altri siti

Crea un account o accedi per commentare

Devi essere un utente per poter lasciare un commento

Crea un account

Registrati per un nuovo account nella nostra comunità. è facile!

Registra un nuovo account

Accedi

Hai già un account? Accedi qui.

Accedi ora
×
×
  • Crea nuovo/a...