Home Page
Articoli
Tips & Tricks
News
Forum
Archivio Forum
Blogs
Sondaggi
Rss
Video
Utenti
Chi Siamo
Contattaci
Username:
Password:
Login
Registrati ora!
Recupera Password
Home Page
Stanze Forum
SQL Server 2000/2005/2008, Express, Access, MySQL, Oracle
Come fare
venerdì 03 giugno 2011 - 08.07
Elenco Threads
Stanze Forum
Aggiungi ai Preferiti
Cerca nel forum
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
ven 3 giu 2011 - 08:07
Salve a tutti, ho questo problema: ho un database access dove sono inseriti i lavori di più teams il mio problema è quello di creare una query che limita l'accesso ai record del singolo team, nel senso che il team "A" non deve conoscere il lavoro del team "B". il problema che cosi posto potrebbe sembrare semplice, non lo è in quanto la query non dovrebbe essere intesa come filtro. ma dovebbe bloccare l'accesso ad altri record in modo completo ne senso che, ad esempio team a non può accedere ai dati di team b neanche chiudendo tutti i filtri.
forse per essere più chiaro spiego cosa dovrebbe verificarsi all'apertura del database:
1 .apro il database come team a;
2 .il database crea una query che nei criteri del campo "team" mi scrive "team A"
in questo modo qualunque oggetto io apra come team a (maschere report ecc) posso vedere ed aggiornare solo il lavoro di team a. logicamente l'aggiornamento del database che faccio come team a 8oppure se apro come team b) ecc deve poi riflettersi sulla tabella generale (ossia del supervisore che può vedere tutto)
qualcuno è in grado di dirmi come fare?
grazie
micto27
Profilo
| Senior Member
385
messaggi | Data Invio:
ven 3 giu 2011 - 11:10
Ciao,
se dall'utente connesso riesci a risalire al Team forse potresti definire una query (es. qCurrentTeam) che sfruttando la funzione CurrentUser()
può, in base all'utente connesso, fornire il team.
Tale query potresti utilizzarla così per filtrare in modo dinamico i dati sui vari oggetti (Maschere, Reports, ecc.).
Michele
ugk111
Profilo
| Junior Member
92
messaggi | Data Invio:
ven 3 giu 2011 - 12:15
cosa ne pensi di creare una semplice query di selezione come la seguente:
SELECT Tabella1.campo1, Tabella1.[campo 2], Tabella1.team
FROM Tabella1
WHERE (((Tabella1.team)="a"));
e poi impostare come origine dei dati nella maschera che andrai ad aprire al posto del nome della tabella il nome della query appena creata.ho provato esattamente così come la vedi e ,per quanto mi sia parso di capire potrebbe fare al caso tuo.in questo semplice esempio funziona anche per l'inserimento di nuovi record nel data base principale
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
sab 4 giu 2011 - 07:47
il probleme è che l'apertura del file anche con la maschera è prevista anche in contemporanea per + team contemporaneamente. certo che potrei fare dalla tabella di origine tante query quanti sono i team. però a tal punto dovrei fare anche tante maschere separate quanti sono i team cioè chreare una specie di sistema parallelo (il team a apre la maschera del team a il report del team a ecc. stessa cosa il team b , il team c) (tra l'altro ho dimenticato di dire che si accede al programma da postazioni diverse). quello che invece io volevo fare è una specie di macro che :
-all'apertura del programma, ad es dal team "c"
-va sulla query diciamo principale,
-la blocca su team "c"
-consente la visualizzazione dei soli record di tutti gli oggetti dipendenti (maschere, report e query create quella principale ) limitati al team c).
-la query principale, per intenderci quella che blocca il tam dovrebbe avere la caratteristica di poter essere contmporaneamente aperta anche da altri team con le stesse possibilità prima descritte per il team "c"
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
sab 4 giu 2011 - 07:48
e come si fa?
ugk111
Profilo
| Junior Member
92
messaggi | Data Invio:
sab 4 giu 2011 - 10:27
non penso sia necessario stravolgere il tutto ,basterebbe parametrizzare la query .ovvero non so se hai una tabella in cui sono registrati i nomi degli utenti, nel qual caso potresti aggiungere ad essa un campo nel quale stabilisci a che team appartengono i singoli utenti e poi la query
SELECT Tabella1.campo1, Tabella1.[campo 2], Tabella1.team
FROM Tabella1
WHERE (((Tabella1.team)="a"));
dovrà essere parametrizzata con il nome del campo contenete il gruppo di appartenenza e quindi sostituire ad "a" il nome del campo. se posso esprimere un modesto parere, meglio sarebbe se l'avvio della procedura avvenisse con una piccola maschera preposta solo al riconoscimento dell'utente ciò sarebbe propedeutico alle operazioni successive.infatti se tale maschera la si mantenesse attiva dopo il riconoscimento dell'utente e si continuassero ad usare altre maschere avente come origine dei dati la predetta query ,le maschere restituirebbero sempre il range di dati da te richiesto. ma una cosa non ho capito e quindi ti chiedo:sulle varie postazioni hai installato copie della procedura che a sua volta punta ad un adata base condiviso o hai fatto dei collegamenti alla procedura e quindi tutta la procedura è condivisa dalle varie postazioni ?
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
sab 4 giu 2011 - 22:09
ok questa mi sembra la soluzione giusta, anzi dirò di più : nel posto dove lavoro ogni utente ha accesso alla postazione come user laddove per user intendo il codice fiscale.
ora quello che vorrei chiederti è come spiegare ad access che ad apertura del database lui deve riconosermi l'user collegato ad un team: per farti un esempio:
cf aaaa è il capo del team "1"
cf bbb è il capo de team "2"
ora io vorrei costruire una macro in base alla quale se come user del pc entra chi il titolare del cf aaa il programma fa vedere solo i record in cui è presente il campo team "1" senza alcuna possibilità che possa vedere i record di team 2, mentre admin fa vedere tutto.
quanto alla tua domanda ti dico che ho creato un unico dbase e per evitare inutili e superflue duplicazioni che questodovrebbe essere poi condiviso nel modo che ti ho detto
come si costruisce questa macro ?
grazie per i suggerimenti
ciao
ugk111
Profilo
| Junior Member
92
messaggi | Data Invio:
dom 5 giu 2011 - 18:08
scusa se insisto ancora con le domande ma ciò potrà essere utile per una mia migliore interpretazione del tuo progetto. e quindi la domanda che vorrei porti : cosa intendi per un unico data base . lo intendi come un unico insieme di tabelle contenente dati , maschere,query e macro oppure intendi le sole tabelle alle quali poi gli utenti accedono per eseguire le varie operazioni di input/output ? è fondamentale capire ciò perchè se hai creato per i vari utenti solo dei collegamenti per utilizzare in condivisione un unica procedura allora quello che chiedi non è assolutamente praticabile , se viceversa hai creato delle copie della procedura e queste sono tutte collegate al solo data base (quello con solo tabelle dati) allora è possibile creare quanto da te richiesto e comunque per realizzare ciò di cui hai bisogno ci sarebbero ,anche se elementari,più passi da fare e non una semplice macro.l'aver creato dei collegamenti alla procedura,se questo fosse il caso, potrebbe sembrare la scelta più pratica ,la più veloce per risolvere i problemi, ma ciò a volte è solo pura apparenza.infatti quando una procedura deve "girare in rete" è ,secondo mio modesto parere, meglio fare delle copie della procedura e collegarle al data base. così facendo ad esempio è possibile personalizzare ogni singola copia per ogni utente
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
dom 5 giu 2011 - 20:26
Allora ti descrivo come è fatto il file formato .mdb:
questo file si compone di due tabelle principali (tipo fornitori e prodotti per intenderci) collegati con relazione uno a molti
alla tabella prodotti, è collegata una query (prodotti .query) che mi serve per dei calcoli. a questa query si accede tramite maschera e sono inoltre collegati -sempre a prodotti.query -due o + report. prima di pensare ad utilizzare la funzion current user avevvo pensato di fare il database principale e tanti database satelliti quanti erano i team che si collegavano al principale tramite tabelle collegate. c'è però il limite che ti dicevo e cioè che il team 1 non deve assolutamente sapere ciò che fa il team 2 e qui sta il problema: quando dico a database di creare dei collegamenti a dati esterni lui me li fa solo con tabelle, non con query. allora l'alternativa quale sarebbe ? creare tante tabelle (quanti sono i team) che vengono collegate ad altrettanti database (quanti sono i team) ad ognuno dei quali accede solo e soltanto il team abilitato.
ma qui sta il problema: come realizzare tutto ciò ?
A) il primo passo dovrebbe essere (penso) quello di creare tante query quanti sono i team;
B) poi queste query dovrebbero essere trasformate in altrattante tabelle.
ma è proprio su B) che casca l'asino: come si fa a fare questo (il terzo passo è semplicissimo: si creano i database con collegamenti esterni con voce "collega"), e soprattutto come si fa a mantenere il carattere dinamico del collegamento con l'ipotetica tabella (originata dalla query filtrata) e collegata al database che potremmo definire satellite?
micto27
Profilo
| Senior Member
385
messaggi | Data Invio:
dom 5 giu 2011 - 23:17
1598_db1.zip
Ciao,
ti passo in allegato un piccolo mdb, nel caso l'idea ti possa servire.
L'esempio abbozzato contiene 2 tabelle
- Tabella1: contiene una serie di righe associate ciascuna ad un Team
- Tabella2: contiene l'associazione dei vari utenti al Team di riferimento (io entravo come utente Admin)
- Query1: filtra il team corrispondente all'utente correntemente connesso
- La maschera Tabella1 sfrutta come origine dati Tabella1 in join con Query1 in modo da filtrare automaticamente
le righe di tabella1 compatibili con il team associato all'utente corrente
Prova a vedere se ti può servire lo spunto.
Michele
luigi60r13
Profilo
| Newbie
6
messaggi | Data Invio:
lun 6 giu 2011 - 06:51
PURTROPPO NON RIESCO A RISOLVERE IL PROBLEMA. COME DEVO FARE QUALCUNO E' IN GRADO DI AUTARMI?
Torna su
Stanze Forum
Elenco Threads
Partecipa anche tu! Registrati!
Hai bisogno di aiuto ?
Perchè non ti registri subito?
Dopo esserti registrato potrai chiedere
aiuto sul nostro
Forum
oppure aiutare gli altri
Consulta le
Stanze
disponibili.
Registrati ora !