Newsgroup: it.comp.appl.access
Titolo: MDB per antiriciclaggio

Sto realizzando un database per la gestione personale dell'antiriciclaggio, 
le specifiche tecniche, mi impongono di non poter effettuare nessuna 
modifica sui dati inseriti. A questo punto mi chiedo se è possibile 
impostare la tabella affinchè sia consentito variare o cancellare i dati 
inseriti ad eccezione di qualche campo, o se questa impostazione è da 
applicare solamente alle maschere.
Ciao e grazie 

 ha scritto nel messaggio 
news:45a107de$0$16153$4faf...@reader3.news.tin.it...

Direi solo alle maschere, che sono l'unico mezzo che l'utente dovrebbe avere per avere una 
comunicazione attiva con le tabelle. Dalle maschere fai tutto quel che vuoi.
Michele 

 ha scritto nel messaggio
news:45a107de$0$16153$4faf...@reader3.news.tin.it...

Non so se ho compreso bene il problema. Tuttavia, mi sembra che tu debba
passare dalla protezione a livello utente.
Potresti provare a dividere le tabelle, separando i campi modificabili da
quelli non modificabili. A questo punto e con la protezione a livello utente
opportunamente settata, le prime sarebbero modificabili dall'utente e le
seconde solo dall'amm/ore. Infine, potresti costruire le form sulle prime e
gestire l'aggiornamento delle seconde da codice.
In tal modo potresti avere delle forms che espongono in sola lettura i dati
delle tabelle riservate.
Non ho provato niente di quel che ho scritto, ma mi sembra che potrebbe
fungere :)
Ciao.
eSQueL

 ha scritto nel messaggio 
news:45a107de$0$16153$4faf...@reader3.news.tin.it...

Probabilmente dovrai tenere traccia di tutte le operazioni sul record:
- inserimento
- (eventuale) modifica;
- (eventuale) cancellazione...
Ciao.
-- 
Sergio MAZZA 

 ha scritto nel messaggio 
news:ent3v4$sv3$1...@tdi.cu.mi.it...

Si, devo tenere traccia di ogni variazione intervenuta sul record, per cui 
sono previsti appositi campi, che deve essere sempre all'interno dello 
stesso file, che servono ad indicare se una registrazione è stata modificata 
o cancellata e della relativa data di variazione.
Il problema è che, utilizzando software di altri sviluppatori, ho l'accesso 
solamente alle maschere in quanto le tabelle sono protette da una pasword 
che non conosco.
Visto che il programma l'ho sviluppato io, vorrei dare l'impressione, in 
caso di verifica del software, di non avere la possibilità di accedere alle 
tabelle, anche se effettiamente vorrei, in caso di necessità, usufruire di 
questa possibilità.
Suddividendo le tabelle dalle maschere e applicando le protezioni a  livello 
utente, in caso tentassi di aprire il database delle tabelle, o tentassi di 
accedervi, mediante la funzione collega tabelle, da un altro db, access mi 
richiederebbe la password?
Tutto questo mi serve solamente nel caso in cui l'accertatore conoca il 
funzionamento di access, in modo da fargli credere che solamente chi ha 
sviluppato il software è in grado di aprire le tabelle e che a mè è concesso 
utilizzare solamente le maschere.
Ciao e grazie 

 mè è concesso utilizzare solamente le maschere.
Secondo me puoi semplificarti la vita adoperando SQL 2005 Express come BE.
Con questo prodotto puoi definire tutte le autrorizzazioni che ti pare sulle 
tabelle e permettere l'operatività sulle tabelle solamente a ruoli applicazione.
Non è una cosa tutta rose e fiori, ma funziona egregiamente e non devi stare 
ad implementare meccanismi che sono invece presenti nativamente.
Ovviamente goderesti anche del fatto che SQL Server ha i trigger, tramite 
i quali potresti allestire un sistema di log nativo del DBMS, indipendente 
dall'applicazione che accede ai dati.
--
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 stare ad implementare meccanismi che sono invece presenti nativamente.
Com'è vero!
Quanto tempo ci vuole (mediamente) per passare a SQL Server? E' da un po' 
che ci sto pensando ma ancora non mi sono deciso.
eSQueL 

 po' che ci sto pensando ma ancora non mi sono deciso.
E' meno tragico di quello che sembra.
Per quanto riguarda i dati, oggi non mi appoggio più nemmeno a "Upsize Wizard" 
di Access, bensì a "SQL Server Migration Assistant for Access".
Per l'applicazione, puoi affidarti in prima istanza anche a "Upsize Wizard" 
ma poi devi sicuramente metterci le mani per aggiustare qua e là.
In ogni caso, il tempo che impieghi adesso nello sforzarti a passare a SQL 
Server come BE te lo ritrovi in futuro, quando vorrai ad esempio realizzare 
un'applicazione web o un'applicazione WinForm basate su SQL.


 che ci sto pensando ma ancora non mi sono deciso.
Convertire un BE richiede poco lavoro, il problema è legato al lato FE.
Gli .ADP richiedono molti sforzi (in buona parte legati a bug e stranezze) e
non hanno futuro, sulla base degli sviluppi della release 2007 di Access.
ODBC funziona bene a patto che si leggano a fondo le specifiche e le si
recepiscano: varie abitudini buone per JET non lo sono in tale
configurazione (FindFirst, query eterogenee, alcuni tipi di query a campi
incrociati, etc).
Saluti.

 ha scritto nel messaggio 
news:875ea355a5b38...@news.tin.it...

Ma questo sql 2005 express è un applicativo che si integra ad access oppure 
è una cosa totalmente estranea per cui si dovrebbero avere altri tipi di 
consoscenze?
Leggendo su internet mi sembra di aver capito che se ho una licenza di 
access, regolare, posso scaricare gratuitamente l'aggiornamento.
Ciao e grazie

 access, regolare, posso scaricare gratuitamente l'aggiornamento.
Non esiste un aggiornamento da Access a SQL Server. Sono due prodotti differenti.
Cio che è gratuito è il download della versione Express di SQL Server 2005.
