Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Non si dispone delle autorizzazioni; problemi di apertura file access mdb
187 views
Skip to first unread message
trabatare
Jun 25, 2019, 9:57:37 AM6/25/19
to
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
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
trabatare
Jun 26, 2019, 8:41:26 AM6/26/19
to
Il giorno martedì 25 giugno 2019 15:57:37 UTC+2, trabatare ha scritto:
> 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.
saluti; aggiungo che una ulteriore ricerca degli errori segnalati dagli utenti ha fornito:
> 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.
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
Massimiliano Amendola
Jun 26, 2019, 2:49:11 PM6/26/19
to
Il giorno martedì 25 giugno 2019 15:57:37 UTC+2, trabatare ha scritto:
MA
trabatare
Jun 27, 2019, 2:32:50 AM6/27/19
to
> > Vi ringrazio per le risposte che potrete darmi: come si capisce...non sono molto esperto.
> >
> > Grazie
> >
>
> Ciao scusa tutti accedono allo stesso file? non l'hai diviso in backend e frontend?
> MA
grazie per il suggerimento.
> MA
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
@Alex
Jun 27, 2019, 2:53:06 AM6/27/19
to
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
trabatare
Jun 27, 2019, 6:00:58 AM6/27/19
to
Grazie della risposta.
Come dicevi alla fine del tuo messaggio...penso anche io che sia più facile a dirsi che a farsi...basta che la mia povera testa capisca :-)
Provo a tradurre in stupidese quello che mi hai scritto: se mi sbaglio ti chiedo di correggermi.
Ma tu dici che si può (e pure conviene) creare automaticamente i link ad ogni apertura di un qualsiasi FE presente in un qualunque client e poi automaticamente de-linkarle alla chiusura del FE stesso.
Ci vorrà del codice, penso.
Non so farlo: devo studiare (o eventualmente mi potresti suggerire dove indirizzare le mie ricerche; sitocomune?)
> 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.
Capito i vantaggi. Grazie
> 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...
Nel mio girovagare alla ricerca di una soluzione ai miei problemi, mi pare di avere letto una cosa simile a quello che proponi tu ma, ancora:
1) non ho idea del codice possibile per il controllo-verifica della versione sulla base della tabella di servizio vs local table
2)devo avere un FE "di servizio", "mio", sul quale lavorare e che rappresenti sempre l'ultima versione (e dal quale accedere al BE per aggiornare la Tabella di servizio circa il numero di versione?); è questo il file FE che indendi vada a sostituire i FE presenti nei vari client?
3) va a sostituire...in automatico? cioè da codice posso: all'apertura di un FE fare il confronto di cui al punto 1ù9 e se siamo sotto di una o più versioni, far chiudere il FE, far partire un file BATCH e far riaprire il FE nuova versione? non saprei porprio come fare...
>
> E' più difficile da spiegare che da fare...
>
come dicevo...di sicuro; basta che mi capisca! :-)
Grazie ancora
GM
Come dicevi alla fine del tuo messaggio...penso anche io che sia più facile a dirsi che a farsi...basta che la mia povera testa capisca :-)
Provo a tradurre in stupidese quello che mi hai scritto: se mi sbaglio ti chiedo di correggermi.
>
>
> La divisione in FE e BE richiede le LINKED TABLE, poi è buona norma, LINKARLE all'accesso e rimuoverle alla chiusura.
per linked table intendi le tabelle collegate che, in effetti, io collego una volta sola, una tantum; faccio il mio BE che contiene le tabelle e il FE che ha solo i collegamenti alle tabelle del BE.
>
> La divisione in FE e BE richiede le LINKED TABLE, poi è buona norma, LINKARLE all'accesso e rimuoverle alla chiusura.
Ma tu dici che si può (e pure conviene) creare automaticamente i link ad ogni apertura di un qualsiasi FE presente in un qualunque client e poi automaticamente de-linkarle alla chiusura del FE stesso.
Ci vorrà del codice, penso.
Non so farlo: devo studiare (o eventualmente mi potresti suggerire dove indirizzare le mie ricerche; sitocomune?)
> 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...
1) non ho idea del codice possibile per il controllo-verifica della versione sulla base della tabella di servizio vs local table
2)devo avere un FE "di servizio", "mio", sul quale lavorare e che rappresenti sempre l'ultima versione (e dal quale accedere al BE per aggiornare la Tabella di servizio circa il numero di versione?); è questo il file FE che indendi vada a sostituire i FE presenti nei vari client?
3) va a sostituire...in automatico? cioè da codice posso: all'apertura di un FE fare il confronto di cui al punto 1ù9 e se siamo sotto di una o più versioni, far chiudere il FE, far partire un file BATCH e far riaprire il FE nuova versione? non saprei porprio come fare...
>
> E' più difficile da spiegare che da fare...
>
Grazie ancora
GM
@Alex
Jun 27, 2019, 6:44:16 AM6/27/19
to
....
...
> per linked table intendi le tabelle collegate che, in effetti, io collego una volta sola, una tantum; faccio il mio BE che contiene le tabelle e il FE che ha solo i collegamenti alle tabelle del BE.
> Ma tu dici che si può (e pure conviene) creare automaticamente i link ad ogni apertura di un qualsiasi FE presente in un qualunque client e poi automaticamente de-linkarle alla chiusura del FE stesso.
> Ci vorrà del codice, penso.
> Non so farlo: devo studiare (o eventualmente mi potresti suggerire dove indirizzare le mie ricerche; sitocomune?)
Si sono 10 righe di codice, e ne trovi in mille posti bastafare una ricerca nel WEB, anche nel vecchio S.C., c'è anche mio vecchio materiale, ma si trova codice più funzinale...
Nella sostanza, inizia a leggere in merito, e fatti un tuo processo logico, perchè solo in base quello scrivi il codice e non viceversa...!
Quindi parti che non devi avere LinkedTable, ma se ne hai...?
Quindi cicli la collection TableDefs, che contiene Oggetti di tipo TableDef, e se questi hanno proprietà che le identificano come Linked, le cancelli...!
Dim tdf As DAO.TableDef
With Dbengine(0)(0)
For Each tdf In .TableDefs
If tdf.Attributes And dbAttachedODBC Or tdf.Attributes And dbAttachedTable Then
.TableDefs.Delete tdf.name
' Oppure
'DoCmd.DeleteObject acTable, tdf.Name
End If
Next
End With
Questo codice lo esegui alla CHIUSURA, ma se il sistema va in CRASH, rischi che alla nuova apertura ci siano...
Quindi io lo eseguirei anche all'apertura...
Cancellate tutte le devi RELinkare, ma per farlo devi avere un'elenco di Tabelle da Linkare.
Io lascio nel BE una Tabella apposita con l'elenco, quindi apro una Connessione al BE diretta, e la puoi fare in vari modi..., apro un Recordset su quella Tabella con l'elenco delle LINKED_TABLE, ciclo il RS ed una alla volta Creo la Tabella con il metodo ADD sulla collection Tabledefs, ed assegno la Proprietà Connect.
Relinkate.
......
> > 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...
>
> Nel mio girovagare alla ricerca di una soluzione ai miei problemi, mi pare di avere letto una cosa simile a quello che proponi tu ma, ancora:
>
> 1) non ho idea del codice possibile per il controllo-verifica della versione sulla base della tabella di servizio vs local table
Devi aprire un Recordset sull'Oggetto Database, stesso procedimento che suggerivo prima per andare a leggere la Tabella con l'elenco delle Tabelle...
Dim db As DAO.Database
set db= Opendatabase(pathBE)
set rst=db.openrecordset("tblname")
....
rst.Close
db.close
Set rst=Nothing
Set db=Nothing
> 2)devo avere un FE "di servizio", "mio", sul quale lavorare e che rappresenti sempre l'ultima versione (e dal quale accedere al BE per aggiornare la Tabella di servizio circa il numero di versione?); è questo il file FE che indendi vada a sostituire i FE presenti nei vari client?
Tu avrai un tuo FE, quando è funzionante, vai a modificare la Versione nella Tabella, lo puoi fare a mano, oppure farti un TOOL di manutenzione... non farei fare nulla di Automatico al FE...!
Da TOOL di manutenzione, io ho un sistema che PUBBLICA la nuova release, emette il File in una Cartella specifica, modifica i dati nella tabella.
Le modifiche possono essere fatte su FE o su BE o entrabi, ci sono modifiche che rendono le vecchie versioni non più compatibili... quindi a seconda di come vuoi essere pignolo nel processo devi crearti dei punti di riferimento più consistenti.
Il FE all'apertura fa diverse cose... la prima è leggere quella Tabella con la VERSIONE, e, nel caso non sia COMPATIBILE invia messaggio con l'obbligo di AGGIORNARE, altrimenti è un consiglio, che uscirà ogni volta finchè non lo fa.
Se si aggiorna, lancio un BATCH oppure un VBS(una voltaavevoun EXE in VB6) che prima chiude l'attuale, poi va a prenderela nuova versione, se la trova ed è raggiungibile, sostituisce la vecchia, poi la lancia il FE...
Questo all'apertura farà sempre il VERSION-CHECK che passerà, poi RELINK-TABLE, e poi fine...
> 3) va a sostituire...in automatico? cioè da codice posso: all'apertura di un FE fare il confronto di cui al punto 1ù9 e se siamo sotto di una o più versioni, far chiudere il FE, far partire un file BATCH e far riaprire il FE nuova versione? non saprei porprio come fare...
Il BATCH deve solo fare un COPIA e RINOMINA se serve... poi eseguire il nuovo.
I comandi DOS li trovi fai qualchericerca, altrimenti fai un VBS, che in sostanza è come il VBA...!
> E' più difficile da spiegare che da fare...
> come dicevo...di sicuro; basta che mi capisca! :-)
>
> Grazie ancora
>
> 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
> Come dicevi alla fine del tuo messaggio...penso anche io che sia più facile a dirsi che a farsi...basta che la mia povera testa capisca :-)
Veramente io dicevo il contrario...! ;-)
...
> per linked table intendi le tabelle collegate che, in effetti, io collego una volta sola, una tantum; faccio il mio BE che contiene le tabelle e il FE che ha solo i collegamenti alle tabelle del BE.
> Ma tu dici che si può (e pure conviene) creare automaticamente i link ad ogni apertura di un qualsiasi FE presente in un qualunque client e poi automaticamente de-linkarle alla chiusura del FE stesso.
> Ci vorrà del codice, penso.
> Non so farlo: devo studiare (o eventualmente mi potresti suggerire dove indirizzare le mie ricerche; sitocomune?)
Nella sostanza, inizia a leggere in merito, e fatti un tuo processo logico, perchè solo in base quello scrivi il codice e non viceversa...!
Quindi parti che non devi avere LinkedTable, ma se ne hai...?
Quindi cicli la collection TableDefs, che contiene Oggetti di tipo TableDef, e se questi hanno proprietà che le identificano come Linked, le cancelli...!
Dim tdf As DAO.TableDef
With Dbengine(0)(0)
For Each tdf In .TableDefs
If tdf.Attributes And dbAttachedODBC Or tdf.Attributes And dbAttachedTable Then
.TableDefs.Delete tdf.name
' Oppure
'DoCmd.DeleteObject acTable, tdf.Name
End If
Next
End With
Questo codice lo esegui alla CHIUSURA, ma se il sistema va in CRASH, rischi che alla nuova apertura ci siano...
Quindi io lo eseguirei anche all'apertura...
Cancellate tutte le devi RELinkare, ma per farlo devi avere un'elenco di Tabelle da Linkare.
Io lascio nel BE una Tabella apposita con l'elenco, quindi apro una Connessione al BE diretta, e la puoi fare in vari modi..., apro un Recordset su quella Tabella con l'elenco delle LINKED_TABLE, ciclo il RS ed una alla volta Creo la Tabella con il metodo ADD sulla collection Tabledefs, ed assegno la Proprietà Connect.
Relinkate.
......
> > 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...
>
> Nel mio girovagare alla ricerca di una soluzione ai miei problemi, mi pare di avere letto una cosa simile a quello che proponi tu ma, ancora:
>
> 1) non ho idea del codice possibile per il controllo-verifica della versione sulla base della tabella di servizio vs local table
Dim db As DAO.Database
set db= Opendatabase(pathBE)
set rst=db.openrecordset("tblname")
....
rst.Close
db.close
Set rst=Nothing
Set db=Nothing
> 2)devo avere un FE "di servizio", "mio", sul quale lavorare e che rappresenti sempre l'ultima versione (e dal quale accedere al BE per aggiornare la Tabella di servizio circa il numero di versione?); è questo il file FE che indendi vada a sostituire i FE presenti nei vari client?
Da TOOL di manutenzione, io ho un sistema che PUBBLICA la nuova release, emette il File in una Cartella specifica, modifica i dati nella tabella.
Le modifiche possono essere fatte su FE o su BE o entrabi, ci sono modifiche che rendono le vecchie versioni non più compatibili... quindi a seconda di come vuoi essere pignolo nel processo devi crearti dei punti di riferimento più consistenti.
Il FE all'apertura fa diverse cose... la prima è leggere quella Tabella con la VERSIONE, e, nel caso non sia COMPATIBILE invia messaggio con l'obbligo di AGGIORNARE, altrimenti è un consiglio, che uscirà ogni volta finchè non lo fa.
Se si aggiorna, lancio un BATCH oppure un VBS(una voltaavevoun EXE in VB6) che prima chiude l'attuale, poi va a prenderela nuova versione, se la trova ed è raggiungibile, sostituisce la vecchia, poi la lancia il FE...
Questo all'apertura farà sempre il VERSION-CHECK che passerà, poi RELINK-TABLE, e poi fine...
> 3) va a sostituire...in automatico? cioè da codice posso: all'apertura di un FE fare il confronto di cui al punto 1ù9 e se siamo sotto di una o più versioni, far chiudere il FE, far partire un file BATCH e far riaprire il FE nuova versione? non saprei porprio come fare...
I comandi DOS li trovi fai qualchericerca, altrimenti fai un VBS, che in sostanza è come il VBA...!
> E' più difficile da spiegare che da fare...
> come dicevo...di sicuro; basta che mi capisca! :-)
>
> Grazie ancora
>
> GM
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
RobertoA
Jun 27, 2019, 6:56:22 AM6/27/19
to
Non so se ho capito bene, ma linki le tabelle OGNI VOLTA che avvii il
programma?
@Alex
Jun 27, 2019, 7:07:40 AM6/27/19
to
...
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
> "..è 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?
Io si, ci sono varie scuole di pensiero... ed ognuno fa le proprie scelte anche in base all'utilizzo più o meno professionale.
>
> Non so se ho capito bene, ma linki le tabelle OGNI VOLTA che avvii il
> programma?
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
RobertoA
Jun 27, 2019, 9:26:26 AM6/27/19
to
Ma coi tempi come la metti?
Nin e' che ci metti 2 secondi a re-linkare tutto
@Alex
Jun 27, 2019, 11:00:09 AM6/27/19
to
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
RobertoA
Jun 27, 2019, 12:22:23 PM6/27/19
to
----------------------------------------
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
@Alex
Jun 27, 2019, 1:18:52 PM6/27/19
to
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
Ciao
@Alex
Roberto Fabbri
Jun 27, 2019, 3:45:12 PM6/27/19
to
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
RobertoA
Jun 27, 2019, 3:53:09 PM6/27/19
to
Il 27/06/2019 21:45, Roberto Fabbri ha scritto:
> 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
> 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
>
Roberto Fabbri
Jun 27, 2019, 7:07:18 PM6/27/19
to
Domani cronometro. Voleva solo significare che anche con db di mole non banale si parla di poco
Roberto Fabbri
Jun 28, 2019, 3:49:28 AM6/28/19
to
Il giorno venerdì 28 giugno 2019 01:07:18 UTC+2, Roberto Fabbri ha scritto:
> 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....
> Domani cronometro. Voleva solo significare che anche con db di mole non banale si parla di poco
RobertoA
Jun 28, 2019, 4:19:44 AM6/28/19
to
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'
Roberto Fabbri
Jun 28, 2019, 4:42:46 AM6/28/19
to
@Alex
Jun 28, 2019, 8:36:29 AM6/28/19
to
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
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
trabatare
Jun 28, 2019, 11:43:15 AM6/28/19
to
>
> 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
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
0 new messages