Newsgroup: it.comp.appl.access
Titolo: Gestionale protetto e stampe modificabili dall'utente, e' possibile ?

Quale sistema ritenete sia piu' efficace per consentire all'utente finale di 
modificare i report esistenti impedendo pero' la modifica o meglio ancora la 
visualizzazione di tabelle, maschere, moduli ?
In prima battuta mi vien da pensare alla divisione del gestionale in due 
parti, i report su di un mdb, tutto il resto su di un altro mdb da 
trasformare poi in mde con all'interno un riferimento al primo file 
contenente i report
Pero' cosi facendo l'mdb con i report ha bisogno della struttura tabelle per 
stampare qualcosa, e poi anche di qualche query e poi anche di qualche 
modulo contenente le funzioni richiamate dai report
Insomma, si potrebbe fare ma non e' una soluzione che mi piacerebbe usare
Se ne esistono di migliori (e credo ci voglia poco) e voleste indicarmele ve 
ne sarei grato
Ciao
RobertoA

 visualizzazione di tabelle, maschere, moduli ?
Premesso che se vede i dati e la struttura dei report, risale
facilmente fino alle tabelle.
Il sistema migliore e' senza dubbio una attenta profilatura delle
utenze e dei diritti su ogni oggetto del DB.
cia'
Max


Senza fare immense rivulozioni, nel mdb ci metti solo le tabelle per i report
e accodi i dati di volta in volta
-- 
-- 
MAssimiliano Amendola
www.accessgroup.it
Cisa - Conferenza Italiana Sviluppatori Access

 ha scritto nel messaggio 
news:figrcf$l4c$1...@tdi.cu.mi.it...


----------------------------------------
'Accodo' nel senso che mi consigli di tenere un 'doppione' dei dati presenti 
nell'archivio principale al solo scopo di stampare ?
E per le modifiche dei dati, per le eliminazioni ?
Dovrei, sull'mdb, cancellare e rifare ogni volta i dati necessari per la 
stampa richiesta ?
Ciao e grazie
RobertoA

 utenze e dei diritti su ogni oggetto del DB.
Cioe' permettere all'utente la visualizzazione/modifica in 'struttura' solo 
sui report ?
E' questo che intendi ?
Ciao e grazie
RobertoA

 E' questo che intendi ?
Esatto! E ogni report in due copie, di cui una in sola lettura, cosi'
se un utente ne sputtana uno oltre ogni possibile limite umano, puo'
recuperarne una copia "pulita" sena romperti los marones ogni volta.
cia'
Max


Una tabella solo per le stampe, elimini e riempi come vuoi
In un file con eigenze diverse, l'ho usato,
e non funziona male
Fai tutto in un attimo e dai l'mdb


 Fai tutto in un attimo e dai l'mdb
Sembra tutto carino, ma......
.....senza andare a scomodare DAO, come consigli di muoversi per accedere
al file MDB separato?
Automation?
E, meglio ancora, se si volesse utilizzare ADO?
E se il vero FE fosse un ADP?
Dicci, dicci :-)
-- 
PBsoft di Gabriele Bertolucci
www.pbsoft.it
skype:pbsoftsolution

 Dicci, dicci :-)
Collego le tabelle dell'mdb nel mde. Semplice e pulito


 Collego le tabelle dell'mdb nel mde. Semplice e pulito
Per gli ADP il problema invece non č cosě semplice.
Al limite si potrebbe pensare di utilizzare il file MDB come server
collegato di SQL.
Oppure, utilizzare l'Automation.


> Collego le tabelle dell'mdb nel mde. Semplice e pulito
Ti scrivo nuovamente perché una cosa non mi torna: dove metti i report?
Se li metti nel FE MDE allora non sono modificabili (come invece era stato
richiesto nel messaggio iniziale di questo thread).
Se li metti nel MDB collegato, come li utilizzi?


 Se li metti nel MDB collegato, come li utilizzi?
Allora mde con le tabelle del'mdb.
nell'mdb i report.
In ogni caso c'è un esempio su AccessGroup.it


 In ogni caso c'è un esempio su AccessGroup.it
L'esempio cui fai riferimento fa uso dell'Automation.
Probabilmente la cosa funzionerebbe anche con gli ADP, ma non ho provato.
Sarebbe interessante studiare un sistema che, una volta referenziato il
file MDB dei report, permetta di accedere ai suoi report magari mediante
proprietà/metodi esposti dal file MDB stesso, magari con una classe.


 classe. 
Certo
