Newsgroup: it.comp.appl.access
Titolo: Nascondere i comandi ma stampare!

Per rendere "sicuro" il database, ho disabilitato le tutte le toolbars,
funzioni, etc... all'apertura del file, con startup di un mia form. 
Tuttavia se tolgo anche la toolbar di default, non ho più la possibilità
di stampare grafici e report, mentre se la lascio mi ritrovo un tastino
che mi permette di aprire la database window ... e addio alla sicurezza
già minima.
Come ne esco?
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 Come ne esco?
Fatti una ToolBar personalizzata con solo il Pulsante
di Stampa e attribuiscila al REPORT.
@Alex.
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 di Stampa e attribuiscila al REPORT.
Thank you! Risolto tutto!


 Come ne esco?
Se il problema è la sicurezza, hai considerato la possibilità di salvare
il database in formato mde? (non sarà più possibile accedere in alcun modo
alla struttura di maschere, report e moduli INDI PERCUI tieniti ben
stretta una copia del sorgente!)
Saluti.
Namor
* * * RISPETTA L'AMBIENTE * * *
Questo messaggio è stato inviato 
usando solo elettroni riciclati al 100%!



Chi l'ha detto.....???
Vedi la struttura, ma non il codice sorgente, se io ti cancello un
Controllo..??
@Alex.

 @Alex.
No, negli mde non vedi nemmeno la struttura e non puoi cancellare
controlli.
Ma parliamo solo della struttura di maschere, report e moduli.
Se qualcuno va a fare modifiche alla struttura delle tabelle, che rimane
accessibile, il dbase potrebbe non funzionare più.
Nell'altro caso (nascondere la finestra database), se io apro un dbase
vuoto ed importo tutti gli oggetti da quello protetto, ho libero accesso a
tutto.
Una buona soluzione potrebbe essere l'applicazione di entrambe le tecniche.
Namor


 Namor
Si non vedi la struttura delle Form, ma ritengo che
il problema maggiore non sia smanettare una FORM o un Report
ma i DATI, contenuti in TABELLE e QUERY.
Ne consegue che l'UNICA protezione del prodotto, in quanto spesso
si realizza una struttura FE_BE, sia quella di strutturare
una protezione a livello UTENTE, proprio per non dare l'accessibilità
del BE alle Tabelle, e tanto meno di poter creare delle QRY_UPDATE
o FORM.
Voglio dire che il problema più grave alcune volte non è dato
dalla possibilità di toccare le FORM, ma quello di PROTEZIONE
dei DATI.


 @Alex.
Certo. La protezione dei dati è sempre stata un punto dolente.
La richiesta originale parlava di rendere "sicuro" il database, senza
specificare se nei dati o nella struttura.
Ci sono diversi modi per proteggere i propri dati, più o meno efficaci, ma
credo che "IL" modo assoluto non esista.
Io ho dei back-end condivisi su server in LAN e configurando i permessi
d'accesso al file già si riesce ad ottenere qualcosina, e solo gli utenti
autorizzati possono vedere il file. Poi volendo si può aggiungere una
gestione utenti nei front-end in modo da dare o negare a ciascun utente
certi privilegi di lettura o lettura/scrittura su sottoinsiemi dei dati.
Però se poi gli utenti "autorizzati" ad accedere al file del back-end
fanno casino sui dati... non si può mica stare dietro alle spalle di ogni
utente del dbase a guardare cosa fa!
Bisogna anche tenere conto degli scopi per cui nasce il database e
dell'ambiente in cui opera, per decidere fino a che livello spingersi con
la "mania" della sicurezza. Oltre certi livelli Access non basta più,
conviene passare ad applicazioni client/server e barricarsi dietro le
protezioni più o meno efficaci dei vari SQL Server, Oracle, Gupta, ecc...
Per esempio, un database di titoli di CD condiviso tra due utenti su due
PC in cross-link non avrà le stesse esigenze di protezione di un database
delle paghe del personale di una grossa azienda.
Morale: se uno che sa il fatto suo ti vuole fregare, è probabile che prima
o poi ci riesca, qualunque cosa noi poveri sviluppatori si possa fare per
impedirlo...
Namor
-- 
* * * RISPETTA L'AMBIENTE * * *
Questo messaggio è stato inviato 
usando solo elettroni riciclati al 100%!


 Namor
Non cocncordo sull'insufficienza di ACCESS, ribadisco che 
la protezione a livello utente di Access è paragonabile
in tutto alla dichiarazione degli utenti di MySQL, Interbase
piuttosto che ORACLE e SQL_Server.
Access eventualmente non è sufficiente solo quando gli accessi 
multiutenza iniziano a caricare il sistema, ma del resto ciò
che fa la differenza è solo il programmatore che riesce a spremere
bene il DB e farlo lavorare come si deve, che non è facile.
