Newsgroup: it.comp.appl.access
Titolo: chiedo una conferma per operazione compact BE in multiutenza, da FE

buongiorno
 
 
SE si riesce a fare in modo che nessun utente sia collegato al BE,
 
(tabelle SOLO ACCESS, i FE si scollegano e poi NON si possono ricollegare per la presenza di un file che funziona da indicatore del blocco del BE da parte del posto amministratore)
 
e quindi NON c'è presenza del file ldb, laccdb
 
si può compattare SENZA procedere allo scollegamento e al ricollegamento delle tabelle del BE ?


Da mia esperienza si... tuttavia io mi muovo(evo) in questo modo:
Client su OPEN dopo Autenticazione Relink,
Client su CLOSE(Rimuovo le Linked)
 
Lato manutenzione, ho un Client dedicato che, attiva un sistema di LogoOff forzato attivando un FLAG lato BE(una tabella dedicata).
Nel Client ho una Form(Hidden) che ogni 10 sec controlla il Flag e se TRUE si sconnette, chiudendo i processi entro 1 min, lasciando il tempo all'utente di chiudere.
 
Il motivo per cui rimuovo le Linked è per questioni di sicurezza, purtroppo espone in chiaro le credenziali e consente una connessione ponte da un Client creato in 1 secondo al Client di gestione... facendo Linked di Linked... 
 
Ovviamente sono considerazioni che vanno pesate e ragionate.
 
@Alex
@Alex


C'e' modo di fare una cosa ad eventi?
Nel senso, invece di 'pollare' ogni 10 secondi da client verso server, 
c'e' modo di 'pushare' qualche evento in partenza dal server verso i client?
E' tipica la richiesta di sconnessione dei client per lavorazioni di 
manutenzione lato server, ma il sistema potrebbe trovare utile 
applicazione anche per chat da client a client, visuaizzazione attivita' 
pbx, visualizzazione schermate proattive in genere, ecc...
 
 
 

 pbx, visualizzazione schermate proattive in genere, ecc...
 
Sono 2 cose diverse il Database ed il Client come tecnologia, il DB vede il Client solo come connessione tramite un Driver ODBC/OLEDB... ed è risaputo che il Driver non genera eventi del DB verso il Client...
Quindi il Database non è in grado di sapere che tipo di Client hai usato, se Access, Excel o Word per accedere ai dati, sa solo che lo fai tramite tramite ODBC...
 
Non si fa Push verso i Client nei sistemi DESK a mio parere.
 
@Alex


 la mia è una cosa semplice semplice,
non volevo consegnare separatamente (dal FE) l'utility di compattazione.
 
la videata iniziale mostra pochi pulsanti (poche procedure)
e NON apre recordset o form
(quindi in questo stato NON c'è il file lde/accde) 
 
 
nella postazione "amministratore"
(che può verificare l'esito del blocco,
e quindi la scomparsa del file lde/accde)
aggiungerò il pulsante <compatta>
 
e metto il controllo di presenza del file lde/accde
per non far apparire il messaggio di errore del sistema
 


Si, ho capito che normalmente 'non si fa'
Sarebbe pero' estremamente efficace ed utile un meccanismo che 
consentisse di comunicare da server a client
 
 
 
 
 
 

 per non far apparire il messaggio di errore del sistema
 
errata/corrige (dovuta ...)
i file di blocco menzionati, generati da Access sul BE,
sono quindi con estensione ldb/laccdb

Roberto non ho detto che normalmente non si fa... ma che non si può... e ti ho spiegato con l'esempio il motivo...!
Di cosa parliamo...? Se è sesso degli angeli... possiamo chiudere.
 
@Alex

Speriamo che nessun client si pianti... altrimenti avrai il file di bloccaggio sempre presente...
 
Di fatto la logica può avere un senso nella semplificazione del progetto.
 
@Alex


Veramente stiamo parlando di una cosa che altri db server gia' integrano
 
http://www.firebirdsql.org/file/documentation/papers_presentations/Power_Firebird_events.pdf
 
 
La mia curiosita' era capire se si poteva imbastire un meccanismo 
simile, usando db di altro tipo, come file un mdb/accdb Access
E' chiaro che, se lato server c'e' solo il file dati, non si possa fare 
niente
Ma se dobbiamo arenarci solo perche' non "..non si puo' .." allora siamo 
gia' sconfitti in partenza
Se il problema non si puo' affrontare frontalmente, allora cerchiamo 
almeno di attaccarlo ai fianchi, di lavorare di gancio, ....

Ma parli dei Trigger... e se approfondisci dovresti confermare che i driver ODBC/OLEDB non li supportano...
 
Access o meglio JET non ha trigger.
In ogni caso non confondiamo applicazioni PHP/web e Desk 
 
@Alex


Gli eventi in Firebird sono una specie di trigger
Dove per trigger intendiamo una serie di istruzioni che il db server 
puo' avviare a certe condizioni (su lettura, su scrittura, su 
canellazione, ecc..) ed e' attivita' completamente invisibile a tutti 
gli altri
Per 'eventi', quando si parla di Firebird, si parla della possibilita' 
per i singoli client di 'registrarsi' all'evento desiderato e venire 
avvertiti quando esso si verifica
In breve e' l'apertura di un canale di comunicazione da server verso i 
client registrati all'evento, che sostanzialmente e' quello di cui si 
stava discutendo
Dal punto di vista dei client, essere 'pushati' invece di pollare
 
 
 


Si è tutto chiarissimo, ma come vedi dal Documento, avviene su un canale di comunicazione aprendo un SOCKET in Send-Receive instaurando una connessione...!
Funziona come funzionano le CHAT a livello concettuale(unidirezionale nel senso che il Server Spara il messaggio al Client connesso che rimane in ascolto), quindi la Comunicazione Client-Server è tra EventTracer(Server Firebird) e Client(Sviluppato) in Listen sulla porta.
 
Quindi è una cosa collaterale... e per nulla banale da inserire in un SW tipo Access, sapeondo che poi non lavora in MultiThread, ti fideresti a fare una cosa simile in una Form(Hidden)...?
Certo che no, andrebbe sviluppata una DLL con interfaccia COM, da istanziare in Access, ma anche quì...
 
Peraltro il famoso WinSock non è più fruibile se non ricordo male, quindi creare codice VBA per gestire il Socket... auguri...
 
Indubbiamente è utile... ma... come dicevo sopra è sesso degli angeli.
 
@Alex