Newsgroup: it.comp.appl.access
Titolo: per individuare postazione che danneggia mdb: è necessario considerare operazioni di NON scrittura ?

Ho la necessità descritta in oggetto,
 
in una situazione di multiutenza (al limite del consentito come situazione di rete), con un' applicazione leggera (SOLO conteggio dei movimenti di articoli commercializzati, quindi UN SOLO "livello di item", dimensioni contenute del BE e della tabella che riceve la stragrande maggioranza delle registrazioni, dimensioni MANTENUTE stabili nel tempo), con prevalenza di postazioni "in lettura" (prelievo dati dal BE e generazione di tabelle locali origine dei report). 
Non ci sono stati problemi per parecchio tempo, ma adesso è ricorrente il danneggiamento del BE.
Confido che possa dipendere da una singola postazione e quindi penso di comporre un file di log locale per ogni postazione "che scrive" (registra o cancella: scrittura sul log PRIMA che nel BE del solo ID della tabella).
 
Per la vostra esperienza-conoscenza si possono "escludere" le postazioni che  solamente prelevano dati dal FE dall'indagine dei possibili generatori di danneggiamento al FE ?
 
 


Il danneggiamento e' ricorrente perche' un mdb in multiutenza funziona minga
Provato piu' e piu' volte, dopo un po' si scassa
C'e' poco da cercare il motivo, si frantuma in tanti pezzi
Una volta e' il driver di scheda rete non aggiornato, un'altra volta e' 
la scrittura contemporanea, un'altra e' qualcos'altro
Il vero motivo e' che un mdb in rete funziona minga
Metti i dati in un db server qualsiasi e stai tranquillo, per sempre

 Metti i dati in un db server qualsiasi e stai tranquillo, per sempre
 
Questa è una situazione in cui ESPLICITAMENTE viene richiesto di usare Access,
a me va bene poiché NON sono attrezzato (né per capacità, né per strumentazione disponibile) a seguire (gestire) richieste complesse.
 
In altre parole questo è il mio "target" (non arrivo oltre ...), in questa azienda ci sono PIU' SoftwareHouse, ma va (molto) bene che questa situazione sia gestita così.
 
Aggiungo, allo scopo di porre un'altra richiesta, che si tratta di un mdb per il BE e di mde per i FE (i PC hanno TUTTI Runtime 2007, con SO Windows 7 e Windows 8.1): siete a conoscenza se va meglio se tutto viene passato ad accdb ? (metterei i Runtime più recenti)
 


 
Non è detto che gli .mdb/.accdb, soprattuto se li tieni regolarmente 
compattati ed eviti i Memo, si scassino come sostiene RobertoA.
Ma in casi come il tuo (reiterate corruzioni) non è facile trovare il Client 
responsabile e soprattutto correggere il problema (schede di rete? Cavi? 
PC?)
 
Ti consiglio di prendere in considerazione servizi per la gestione remota 
(Terminal Server): è un compromesso che funziona.
 
Saluti.
 
 

 
grazie per l'attenzione
 
ma voglio insistere sugli aspetti dell' applicazione e continuo il colloquio
proprio perché, come in modo indiretto si può capire, ritengo questa una situazione "da Access": 
si lascia sul posto una propria realizzazione E SI AVVERTE dei limiti, 
si risolve una questione che LE PRESENTI SH, in pratica, NON POSSONO affrontare nei termini di operatività richiesti (personalizzazione "spinta", questione NON affrontabile "a progetto - a tavolino").
 
Allora:
DOPO aver avvertito dei limiti di connessioni (8-10 postazioni) sono partito con 4-5 posti che potevano registrare e 6-7 posti che stampavano solamente
(quindi SOLO prelievo dei dati, ma disposto in modo tale di agire SU COPIA LOCALE, quindi in ritardo rispetto alle registrazioni). 
L'azienda chiede di mettere TUTTI "in linea" (tempo reale per le stampe) e aumenta anche qualche posto (e io continuo con l'avvertimento: ci sono collegamenti con wifi, NON c'è neppure un "server dedicato" ...)
 
Personalmente ritengo che sia il "server" a non reggere il traffico
(vedo in rete che Microsoft ha tolto il limite "di targa" delle connessioni IP supportate per Windows 7 e 8, ma noto anche che alcuni sistemisti si attengono ad un limite pratico di 20),
appaiono gli errori 3343 e 3109: i FE quindi si aprono ma "perdono la linea" 
(e poi UNA MACCHINA in particolare "non scrive bene").
 
Certamente riproporrò la disposizione che i posti che stampano solamente agiscono prelevando una copia locale (e intanto si tiene fermo il PC che "scrive male"), ma questa particolare realizzazione mi porta a fare considerazioni (che poi sono richieste) su cosa possa incidere sul "carico" del server:
 
1) mantengo la connessione stabile con una listbox nascosta nella mainform 
(origine: tabella del FE), E ANCHE "stacco" il FE dopo 15 di inattività (questo per i posti che stampano). 
Mi sa che questa seconda opzione NON "riduca" il carico sul server ("picchi" di ricollegamenti ?, LDB che comunque NON si chiude !) 
 
2) "il posto server" ha la possibilità di scollegare tutti (indicatore rilevato da hidden form del FE) per eseguire il calcolo di ricompattazione quantità e la ricompattazione del BE (ovviamente durante l'orario di lavoro ...). 
Toglierò anche questo indicatore dal BE, generando un file di testo (basta solo il nome) la cui presenza viene testata dagli script di avvio FE
 
3) le poche form (con subform) di inserimento dati (articoloCodice-articoloColori, movimentoTestata-movimentoRighe) sono associate (quindi "è il sistema che scrive"), ma ho l'abitudine di tenere la generazione degli ID di riga con istruzioni di recordset (apro una tabella di soli contatori, aggiungo la riga e prendo il numero, ho tante tabelle quanti sono gli ID "numerosi").
QUINDI attivo una seconda modalità di scrittura (che può anche essere evitabile). 
 
ecco la domanda (per chi può dire qualcosa): quanto "pesa" per il server avere richieste di scrittura SOLO da oggetti di Access rispetto ad avere richieste "aggiuntive" da comandi SQL e aperture di recordset (evitabili) ?
 
 
 


EDIT:
1) mantengo la connessione stabile con una listbox nascosta nella mainform 
 (origine: tabella del BE),


 
 
Nel corso dei lustri sono state sviluppate ovunque applicazioni basate su 
Jet/Ace, spesso usate con multiutenze significative.
Programmi piccoli, ma anche molto grossi.
A volte tutto funziona per anni, se non per lustri, senza alcun problema (DB 
compattati, no Memo), poi improvvisamente un diavoletto si mette a 
corrompere il DB quotidianamente. E questo puň capitare anche su 
applicazioni e Databases piccini...
Le cause sono difficile da individuare e a volte impossibili da risolvere.
 
Considerando le caratteristiche della rete su cui girano i tuoi programmi 
(WiFi, connessioni al server che si staccano) ci sono due soluzioni:
 
- SQL Server express edition  (ma alcuni usano MySQL o FireBird), che 
comporta un lavoro di conversione non necessariamente difficile, ma che 
costa tempo
 
Oppure
 
- Gestione remota: con un servizio tipo Terminal Server (ma ce ne sono di 
molto piů economici) fai girare tutto sul Server e attraverso la LAN 
passeranno solo i segnali Video ai vari Clients. Se s'interrompe una 
connessione non succede assolutamente nulla. I programmi non devono essere 
rivisti o modificati.
 
 
Saluti.