Newsgroup: it.comp.appl.access
Titolo: Corruzione Tabelle.mdb gestito da .accdb

Buongiorno a tutti,
 
Ho un BE Tabelle.mdb a cui accedo da vari FE in formato .accdb.
 
Non ho trasformato il mdb in accdb perché ho un macchinario che accede 
a quelle tabelle ed usa un software non mio (linkato a Tabelle.mdb).
Inoltre avevo letto in giro che questo tipo di configurazione non 
dovrebbe dare problemi.
 
Adesso mi capita che 2/3 volte al mese il Tabelle.mdb si corrompe.
 
Secondo voi, queste corruzioni possono essere attribuite 
all'architettura accdb/mdb oppure devo ricercare altri motivi?
 
Grazie.
 
Ciao.
 
Silvio


Io voto per il si
Ho avuto dolorose esperienza parecchi anni fa legate alla corruzione 
archivi dati in formato Access condivisi da piu' postazioni
Si parlava di Access 97, erano bachi noti e attribuibili a driver schede 
rete non aggiornati, ma c'erano
E puntualmente ogni tre per due chiamavano avvertendo che bisognava 
correre perche' l'archivio si era scassato "..come l'altra volta.."
E non su un'installazione ma su piu' d'una, con pc diversi, programmi 
diversi, operatori diversi
Ed e' anche comprensibile, se non c'e' qualcosa che dirige le operazioni 
(come fa un db server) prima o dopo la magagna succede
E' solo questione di tempo
Da quella volta ho detto 'basta, con gli mdb per i dati ho chiuso'
Ce ne sono molti di db server buoni, gratuiti, assistiti
Il problema nel tuo caso e' quel software che non puoi toccare
Ma li bisogna farglielo capire al responsabile della baracca, o segue te 
e c'e' speranza di sistemare le cose oppure non si tocca niente e tra 10 
giorni risuccede


condivido di aver i dati su db server 
ma come front end ?
c'e' qualcosa di alternativo senza dover utilizzare visualstudio ?


Il fatto che il BE sia un MDB, non dovrebbe dare problemi se il FE è un ACCDB, la variante che può emergere è solo il DRIVER di connessione ACEDAO al posto di DAO...
 
Spesso tuttavia i fenomeni di corruzione sono dovuti ad accessi concorrenti o a query che falliscono.
 
Io ritengo che la causa sia da cercare altrove, ci sarebbe da capire ad esempio se nel tuo sviluppo fai uso del modello transazionale o meno... pur con i limiti delle transazioni di Access...
 
Chiaramente la premessa a tutto è che un database come JET non è nato per dare un livello di affidabilità elevato, ne sono dimostrazione proprio gli aspetti di gestione delle transazioni... o gli aspetti di sicurezza... senza parlare della funzionalità del motore.
 
Personalmente ti suggerirei di provare a valutare una migrazione ad un Server più adeguato, magari SQL_EXPRESS che è gratuito.
Con questo puoi imparare come ottimizzare le prestazioni, l'uso del T-SQL e soprattutto la potenza delle transazioni e dei ripristini tranzazionali...
 
Saluti
@Alex

Il 30/05/2018 19:10, Silvio ha scritto:

mdb come be li evito come la peste da 10 anni propio per quei motivi
spingi l'altra software house a migrare su sql express e dormi tranquillo
 
BFS


Come front end usi Access
O Visual Studio
O Delphi
O Oracle Forms
O .....

 
 
 
solo per aggiungere un punto di (s)vista,
considerando anche che possano mancare le "piene collaborazioni"
 
C'è la possibilità di mantenere "distinte" la due procedure ?
 
In altre parole se NON avviene uno scambio di registrazioni
e quindi il "blocco tabelle mdb" è un fornitore di dati
e le tabelle non sono molte 
 
si può provare ad IMPORTARE il blocco invece di collegarlo
(certo: si perde in immediatezza anche perchè occorre ripetere "in continuo", comunque se è possibile si giustificherebbe bene come "mossa transitoria")

GiorgioDaPrato scriveva il 31/05/2018 :

Buongorno GiorgioDaPrato e grazie per la risposta.
 
Non sono sicuro di aver capito bene il tuo punto di (s)vista ma... sì, 
con qualche complicazione posso "buttare fuori" il macchinario e 
gestirlo esternamente. Quindi lui continuerebbe a lavorare su 
Tabelle.mdb mentre io potrei passare su MieTabelle.accdb.
 
Mi domando se potrei risolvere il problema cioè se in un'architettura 
FE/BE un accdb/accdb potrebbe essere più affidabile di un accdb/mdb...
 
Grazie.
 
Ciao

Silvio ci ha detto :

Grazie e tutti per le risposte.
 
Dunque, da quanto mi dite, un'architettura accdb/mdb potrebbe NON 
essere il problema.
 
Devo assolutamente trovare il tempo per fare il passaggio a SQL 
EXPRESS...
Come dicevo in un altro post (mesi fa) avrei bisogno di un 
sito/manualetto "getting started" ma soprattutto mi manca il tempo. Ci 
proverò.
 
Grazie ancora.
 
Ciao
 
Silvio

 Tabelle.mdb mentre io potrei passare su MieTabelle.accdb.
 
mi ero raffigurato questa situazione:
 
i dati presenti nel blocco tabelle mdb sono registrati da una procedura "esterna" (NON Access o Access <=2003) SOLO su una postazione
 
la "tua" procedura NON effettua registrazioni nel blocco mdb, 
ma li utilizza, in multiutenza, per report e ricerche su form 
 
per cui la  "mossa temporanea", con effetto da verificare, è quella di importare il blocco tabelle mdb nel FE accdb distribuito in multiutenza
 
la multiutenza così NON ha due tipi di tabelle, 
ma questo NON esclude la possibilità di corruzione del blocco mdb !!! 
stante l'esecuzione praticamente continua delle varie istruzioni di import
e quindi del permanere di molte operazioni contemporanee sul blocco mdb
(fra l'altro: come si può affermare che sia la "tua" procedura a danneggiare il blocco mdb ?)
 
 
se la situazione è questa, e portando all'estremo, in attesa di sqlServer: 
si può "fissare" il blocco tabelle mdb in una copia di tutto il file, o in files di testo, e da lì eseguire le import dati
 
 
ma niente è "estremo" rispetto alla corruzione dei dati
 

GiorgioDaPrato ha spiegato il 01/06/2018 :

OK, grazie.
Comincio o spostare il macchinario alieno e a passare in accdb ma ho 
capito che la priorità dev'essere il sql server...
 
Grazie mille.
 
Ciao