Newsgroup: it.comp.appl.access
Titolo: Non si dispone delle autorizzazioni; problemi di apertura file access mdb

Buongiorno
ho cercato all'inteno del gruppo una risposta alle mie domande: ho imparato che c'è tutto un mondo relativo ai "proprietari" e agli utenti che proprio non conoscevo; ma la mia domanda non ha trovato (apparentemente) risposta.
 
sono a chiedervi un aiuto, se possibile.
 
c'è un file mdb creato dal sottoscritto un milione di anni fa in access97 e via via modificato nel tempo con le varie versioni disponibile presso l'ufficio con il quale ogni tanto collaboro e per il quale, appunto, ho creato tanti anni fa questo piccolo gestionale. Veramente semplice, niente di complicato. Negli anni il gruppo e il sitocomune mi hanno aiutato a renderlo un po' meno peggio di quello che era :-)
 
il file giace sul server dell'ufficio, circa 30 Mb il suo peso, che cala a 25 dopo il compatta e ripristina che ogni due tre giorni faccio; ogni postazione (15 per la precisione) ha accesso tramite un semplicissimo collegamento sul desktop.
Sulle macchine è installato Access 2013
 
Nesun problema di apertura fino ai nostri giorni.
Ultimamente (circa un mesetto) comincio a vedere nella cartella in cui giace il file, diversi files di backup, segnale di un qualche crash che gli utenti (ovviamente) non sanno descrivermi (della serie: "prima andava poi non andava, ho chiuso ho riaperto e adesso va"....)
 
Non solo: in mia presenza si è verificata, all'apertura del file col semplice doppio click sul collegamento, la famosa frase "non si disponde delle autorizzazioni etc etc".
(Ho ovviato con il ripristino del file di backup di pochi minuti prima  = sotituzione del file non apribile con il file di backup)
 
Eppure in tanti anni non mi sembra di avere dato o negato autorizzazioni di qualunque tipo a nessuno (magari sapessi come si fa, aggiungo).
 
la cosa ancora più strana (a patto di credere che il messaggio di errore sia il medesimo) è che mi hanno segnalato che "non facendo niente" dopo un po' il file si apriva, da ogni postazione, in maniera naturale. (non metto la mano sul fuoco che il messaggio sia quello legato al contattare il proprietario, ma la segnalazione viene da un utente non prorpio stupido).
 
Non so che pesci pigliare.
1) e' un problema di versione? converto il file in versione corrente (facendolo file accdb)?
2) è un problema di accesso contemporaneo allo stesso file da parte di troppe postazioni?
3) è un problema di accesso da parte di una particolare postazione che "prevale" sulle altre: aperta lei le altre non possono accedere? ma allora qual è la postazione, in questo caso?
4) è un problema di autorizzazioni, peraltro mai cambiate o mai (apparentemente) date o negate? a costo di incorrere in problemi di sicurezza, io preferisco che tutti abbiano accesso e autorizzazione a tutto. Ma come si fa?
 
Vi ringrazio per le risposte che potrete darmi: come si capisce...non sono molto esperto.
 
Grazie
 
GM 

 sono a chiedervi un aiuto, se possibile.
 
 
saluti; aggiungo che una ulteriore ricerca degli errori segnalati dagli utenti ha fornito:
1. stato non coerente (e conseguente ripristino e creazione di un backup): ho studiato e trovato un vecchio thread che ne parlava, con una ottima risposta di Karl D.; si tratta di problemi relativi all'accesso multiplo (e simultaneo?); studierò e provvederò con i correttivi proposti
 
2. errore 2001: anche qui mi soccorrono i vecchi thread relativi alla attendibilità; ho abolito la macro autoexec, retaggio dei tempi antichi implementando il codice nell'evento su aperturra della maschera iniziale; ho eliminato la mascro autoexce 8in realtà rinominata OLD); domanda:le due o tre macro ancora presenti (e per le quali non sono sicuro che servano ancora: approfondirò) per il solo fatto di essere presenti, possono portare al medesimo errore 2001? o solo la loro attivazione fa scattare il problema di affidabilità?
 
3. resta il problema del "proprietario", come da mia domanda principale nel primo post.
 
Saluti ancora
 
GM
 

Il giorno martedì 25 giugno 2019 15:57:37 UTC+2, trabatare ha scritto:

Ciao scusa tutti accedono allo stesso file? non l'hai diviso in backend e frontend?
MA

 MA
 
grazie per il suggerimento.
Credo di avere capito che la separazione tra BE e FE permette il non sovraccarico della rete (oltre a non andare incontro a problemi di stato incoerente? o il problema rimane? Mi pare che in un post del dicembre 2018 KArl D. riportasse il problema, indicando il seguente link: 
https://support.office.com/it-it/article/access-segnala-che-i-database-sono-in-uno-stato-incoerente-7ec975da-f7a9-4414-a306-d3a7c422dc1d
).
 
Ho studiato e ho capito che la divisione in BE e FE avrebbe per me un problema "insormonabile": se la versione FE deve risiedere sui client (le postazioni), le modifiche che eventalmente dovessi fare ad una maschera, dovrebbe essere replicata sulla decina di client presenti; non so se possa bastare un semplice "eliminazione del file FE vecchio e inserimento del file FE nuovo"...non dovrei nuovamente ripristinare i collegamenti alle tabelle presenti nel BE?
 
riguardo all'insormontabilità del problema: non è veramente insormontabile...è che penso che (al netto di altri ragionamenti che non riporto):
- il file, depurato da inutilità varie, arriva a pesare 15 mb...
- l'accesso massivo capita raramente (ma capita)
cioè che andare ad aggiornare i 10 client ad ogni modifica...mi risulta pesante, non facendolo per lavoro.
 
Ti ringrazio del suggerimento, per il momento.
Grazie
 
GM
 


La divisione del sistema in FE e BE è doverosa se si lavora in MultiUtenza, inquanto altrimenti il FileSharing del tuo applicativo non è una gran bella cosa...!
 
La divisione in FE e BE richiede le LINKED TABLE, poi è buona norma, LINKARLE all'accesso e rimuoverle alla chiusura.
Questo ha vari vantaggi, non consentire il RELINK da DB autocostruiti attraverso il Ponte delle tue LINKED presenti... o meglio se il tuo FE chiuso mantiene le LINKED Table(magari autenticate con PWD) ed io sul PC apro un Nuovo ACCDB e Faccio il LINK delle Tue LINKED_TABLE non ho bisogno di PWD... il doppio ponte funziona... e non è bellisismo.
Altra cosa è che se modifichi il BE nella struttura le Tabelle vanno relinkate altrimenti rischi anomalie sull'accesso ai dati.
 
Detto questo, se poi generi un'aggiornamento del FE, ti basta ragionarci un poco prima... e predisporre nel BE una tabella di Servizio in cui inserisci l'Ultima VERSIONE del FE disponibile...
Nel FE crei una LOCAL TABLE con la Versione del FE, ed all'apertura Il FE controlla che la propria VERSIONE corrisponda a quella nella Tabella del BE.
Se così non è, fai chiudere tutto e lanci un File BATCH che Copia il NUOVO, lo sostituisce al Vecchio e lo lancia...
 
E' più difficile da spiegare che da fare...
 
@Alex

 
 
come dicevo...di sicuro; basta che mi capisca! :-)
 
Grazie ancora
 
GM
 

 GM
 
Alla base, se non hai un minimo di base di programmazione, abbiamo fatto scuola, ma non riuscirai a farlo se non mettendoti li piano piano, studiando le varie soluzioni che trovi in rete in modo "CRITICO" non adattandoti al semplice COPIA/INCOLLA altrimenti non capisci nulla e continuerà a non funzionare...
 
Sopra hai "del codice" che inse fa tutto ma non fa nulla nel senso che lo devi assempblare congnizione...
 
Quindi, dare martellate sono capaci tutti, diceva il carroziere..., è darle bene e nel posto giusto per ottenere la riparazine e non dei danni il problema.
 
Buon lavoro.
 
@Alex 


"..è buona norma, LINKARLE all'accesso e rimuoverle alla chiusura..."
 
Non so se ho capito bene, ma linki le tabelle OGNI VOLTA che avvii il 
programma?
 
 
 
 

 programma?
 
Io si, ci sono varie scuole di  pensiero... ed ognuno fa le proprie scelte anche in base all'utilizzo più o meno professionale.
 
Io come motivo di ragionamento uso quello che ho anche spiegato.... non lascio MAI una LINKED table nel FE, perchè la Connect property che, come sicuramente sai, è leggibile nel FE nella Tabela di Sistema MsysTable è in chiaro... e vedi sia percorso che pwd... e sappiamo bene che la sicurezza di msAccess non è il suo punto forte.(cosa un poco differente era prima quando si usava la Protezione a livello Utente confile MDW).
 
Quindi in sostanza io la reputo un pericolo, non solo per la possibilità di fare un BRIDGE da un FE esterno, ma proprio perchè è tutto in chiaro...
 
Tu pensi sia una cosa saggia...?
 
@Alex


Saggio e' saggio
Ma coi tempi come la metti?
Nin e' che ci metti 2 secondi a re-linkare tutto
 
 


Ma si ovviamente non è ISTANTANEO... dipende anche dalla rete.
 
Si tratta di CREARE un oggetto Tabledef in Locale, assegnare il Nome e la proprietà Connect e fare l'append alla collection...!
 
Carico nel rs l'elenco che leggo dal SERVER e ciclo, quindi di fatto è un lavoro in LOCALE in MEMORIA, deve essere un FULMINE.
 
Ho provato a guardare con un piccolo DB che ho ascopo di sicurezza.
Scenario tutto Access sia FE-BE.
 
IL BE sono 89 Tabelle, di cui 2 non le Relinko in quanto sono diservizio.
1° Elenco Tabelle da LINKARE
2° VERSION_CHECK
 
Queste 2 Tabelle contengono pochi Records.
 
Le altre 87 vengono LINKATE
 
La dimensione del BE è di poco più di 200MB, non è un fenomeno come casistica ma nemmeno il DB delle ricette di casa...
 
Il FE effettua il RELINK delle Tabelle in 5 secondi.
Il DeleteLink impiega leggermente di più, 9s, ma si deve chiudere tutto....
 
Fai attenzione nel tuo CODICE, chenon conosco, a come effettui il RELINK.
Se utilizzi ad esempio il DoCmd.TransferDatabase, per linkare è ovvio che possa impiegare molto, in quanto questo metodo, ha una particolarità, va ad aggiornare la NAVIGATION PANE, quella laterale, e se lo usi ogni volta, ad ogni LINK aggiorni... e perdi un sacco di tempo.
Agendo invece sulla COLLECTION TABLEDEFS, non aggiorni nulla dell'interfaccia grafica, ed infatti non vedrai le LINKED TABLE finchè non premi F5... 
Ma io la NavigationPane la rimuovo, quindi non mi serve.
 
Stessa cosa vale peril DELETE, se usi il DELETEOBJECT...
 
Ti posto il Codice pari pari che ho scritto per il RELINK nella SplashForm.
Devi avere una Tabella nel BE[_LKTBL] che io uso per leggere l'elenco... fai anche attenzione che il tutto avvienesempre con un RECORDSET aperto sul BE, quindi con una Connection nel POOL già aperta... e non la deve ricreare tutte le volte.
 
Se fai qualche prova in confronto con il tuo sistema magari poi dai riscontro, anche per capire se questo approccio è utile.
 
Option Compare Database
Option Explicit
 
Private Const sRemoteBE = "\\PercorsoReteRemoto\BE.accdb"
Private Const sRemoteTBL = "_LKTBL"
 
Private Sub Form_Load()
    If DeleteLinkedTable(sRemoteBE) Then
        Call ReLinkTable(sRemoteBE)
    End If
End Sub
 
Private Sub Form_Unload(Cancel As Integer)
    Call DeleteLinkedTable(sRemoteBE)
End Sub
 
Function DeleteLinkedTable(Optional RemoteBE, Optional Password) As Boolean
    On Error GoTo ERR_Handler
    Const cObjNotExist = 7874
    Const cTableNotExist = 3265
    Dim db      As DAO.Database
    Dim dbL     As DAO.Database
    Dim rs      As DAO.Recordset
    Dim strPWD  As String
 
    If IsMissing(RemoteBE) Then Err.Raise "10000", "RelinkTable", "BackEnd parameter to Relink Function is missing...!"
    If Not fileExists(CStr(RemoteBE)) Then Err.Raise "10001", "RelinkTable", "BackEnd not exist...!"
 
    If Not IsMissing(Password) Then strPWD = ";PWD=" & Password
    Set dbL = CurrentDb()
 
    Set db = OpenDatabase(RemoteBE)
    Set rs = db.OpenRecordset(sRemoteTBL, dbOpenSnapshot, dbReadOnly)
    If Not rs.EOF Then
        rs.MoveFirst
        Do Until rs.EOF
            dbL.TableDefs.Delete rs!tablename
            DoEvents
            rs.MoveNext
        Loop
        DBEngine(0)(0).TableDefs.Refresh
    End If
    DeleteLinkedTable = True
 
Exit_Here:
    On Error Resume Next
    rs.Close
    db.Close
    Set db = Nothing
    Set rs = Nothing
    Exit Function
 
ERR_Handler:
    Select Case Err.Number
        Case cObjNotExist, cTableNotExist:    Resume Next
        Case Else:              MsgBox Err.Number & vbNewLine & Err.Description
    End Select
    Resume Exit_Here
End Function
 
Function ReLinkTable(Optional RemoteBE, Optional Password) As Boolean
    On Error GoTo ERR_Handler
 
    Dim db      As DAO.Database
    Dim tdf     As DAO.TableDef
    Dim rs      As DAO.Recordset
    Dim strPWD  As String
 
    If IsMissing(RemoteBE) Then Err.Raise "10000", "RelinkTable", "BackEnd parameter to Relink Function is missing...!"
    If Not fileExists(CStr(RemoteBE)) Then Err.Raise "10001", "RelinkTable", "BackEnd not exist...!"
 
    If Not IsMissing(Password) Then strPWD = ";PWD=" & Password
 
    Set db = OpenDatabase(RemoteBE)
    Set rs = db.OpenRecordset(sRemoteTBL, dbOpenSnapshot, dbReadOnly)
    If Not rs.EOF Then
        rs.MoveFirst
        Do Until rs.EOF
            With DBEngine(0)(0)
                Set tdf = .CreateTableDef(rs!tablename)
                tdf.Connect = ";Database=" & RemoteBE & strPWD
                tdf.SourceTableName = rs!tablename
                .TableDefs.Append tdf
            End With
            DoEvents
            rs.MoveNext
        Loop
        DBEngine(0)(0).TableDefs.Refresh
    End If
    ReLinkTable = True
Exit_Here:
    On Error Resume Next
    rs.Close
    db.Close
    Set db = Nothing
    Set rs = Nothing
    Set tdf = Nothing
    Exit Function
 
ERR_Handler:
    Select Case Err.Number
        Case Else: MsgBox Err.Number & vbNewLine & Err.Description
    End Select
    Resume Exit_Here
End Function
 
Function fileExists(s_fileName As String) As Boolean
 
    Dim obj_fso As Object
 
    Set obj_fso = CreateObject("Scripting.FileSystemObject")
    fileExists = obj_fso.fileExists(s_fileName)
 
End Function
 
Saluti
@Alex


Si, credo usiamo lo stesso metodo per relinkare
----------------------------------------
Set tdf = CurrentDb.CreateTableDef(nome_tabella)
tdf.connect = "ODBC;DSN=ciucciamariuccia;UID=sa;PWD=sa"
tdf.Attributes = dbAttachSavePWD
tdf.SourceTableName = "dbo." & nome_tabella
CurrentDb.TableDefs.Append tdf
Set tdf = Nothing
----------------------------------------
Io lo faccio solo quando cambia struttura il db
5 / 87 = 5-6 mSec circa a tabella, siamo sugli stessi valori
C'e' un grosso problema di tempi con db che hanno un numero tabelle 
superiori al centinaio
Considero che "un'attesa limite" per l'operatore sia sui 6-7 secondi, 
poi inizia a premere robe a task-managerare a chiamare su wa
 

Si condivido... Credo che 5÷7 secondi sia accettabile... e per ridurre lo stress all'utente gli mostro la barra di progressione così vede che è vivo... 
 
Ciao
@Alex

Be SQL di circa 2 gb, almeno 180 tra tabelle e viste, db locale x ogni postazione, almeno 20/30 tab. Relink ad ogni avvio, come Alex con textbox che mostra la tabella in collegamento. PC assolutamente non performanti. Max 20/22 sec x l'intera procedura, compreso l'avvio di un sw pilota x cercare aggiornamenti

 
 
20 secondi, a me paiono un po' troppi

Domani cronometro. Voleva solo significare che anche con db di mole non banale si parla di poco 

 Domani cronometro. Voleva solo significare che anche con db di mole non banale si parla di poco
 
Confermo. Circa 20 sec. Comprensivo di download di file per controllare la versione corrente, confronti vari e creazione dei record di servizio giornalieri. Visto cha avviene solo all'avvio della sessione di lavoro, non capisco proprio perchè siano tanti. Praticamente ad aprire word non è che ci voglia tanto di meno....


Non so che pc abbia tu, ma il mio Word si apre in 1-2 secondi la prima 
volta, dalla seconda in poi e' ovviamente istantaneo
"..non capisco proprio perchè siano tanti.."  non e' che sia da capire 
qualcosa, sono riferimenti che ognuno si pone di suo
Per te 'non sono tanti'
Per me 'sono troppi'
 


Perfetto così

Word impiega da 5÷8 secondi sia alla prima che alla seconda se sparisce dai processi in esecuzione... un Po come GetObject e CreateObject...
 
In ogni caso ognuno giustamente ha propri riferimenti, proprie competenze e propri livelli... ma se si scrive in un forum credo sia anche per avere dei confronti... altrimenti ognuno si tiene la propria idea e va sempre bene.
 
@Alex

 @Alex
 
volevo ringraziare tutti per i preziosi spunti che mi avete fornito; dovrò dedicarr del tempo per capirli appieno e metterli in pratica ma ho una ottima base da cui partire!
Mi dispiace non poter apportare molto al newsgroup (che mi è venuto in aiuto in diverse occasioni) se non in termini di domande...ma sono solo un "utilizzatore finale" prestato alla (piccola) programmazione per gli amici degli amici.
Ogni vostro consiglio è stato prezioso e, se può servire, vi terrò informati dello stato avanzamento lavori.
Grazie ancora.
 
GM