Newsgroup: it.comp.appl.access
Titolo: PROTEZIONE CLIENT/SERVER

Per ovviare al problema di avere nel client tabelle collegate (se uno quando 
il client è in esecuzione punta al client da un db access nuovo e seleziona 
di collegare/importare le tabelle, può accedere ai dati del Server...), non 
uso tabelle collegate ma tramite ADO mi connetto al Server.
Il mio problema è usare come source di una combolist, una query SQL che 
punta ad una tabella presente sul DB Server senza che detta tabella figuri 
come tabella collegata? Qualcuno ha idea di come si possa fare?
Grazie, Renato. 

 wrote in message
news:u7utf.23504$
eD5.3...@twister2.libero.it

Credo che tu stia affrontando il problema in modo anomalo.
Secondo te tutti quelli che usano tabelle Linkate creano
applicazioni non sicure....????
Spero tu non abbia questa convinzione, anzi prova ad ipotizzare
che non stai operando nel modo corretto.
Se proteggi il tuo MDB in modo adeguato la possibilità di
linkare nuove tabelle non c'è e ti eviti tutte queste "pippe"
Mai sentito parlare di protezione utente ?
Hai provato anche a togliere i Menù standard per inserire i 
tuoi menù personalizzati in modo da evitare possibilità di 
scelte non volute...?
Hai inserito la protezione sul codice da VBE...?
Hai tolto la possibilità di premere lo SHIFT all'avvio..?
Saluti.
@Alex
-- 
Posted via Mailgate.ORG Server - 
http://www.Mailgate.ORG

 ha scritto nel messaggio 
news:dab5ce8da299aba4c9...@mygate.mailgate.org...


"Renato Mulinacci"

In aggiunta a quanto scritto da Baraldi: gli utenti sono "utenti" o
"sviluppatori"?
Se sono semplicemente "utenti" non c'è ragione che sulle postazioni di
lavoro sia installato Access: devi ricorrere alla distribuzione Runtime, e
le tue preoccupazioni cadranno automaticamente.
Se alcuni di loro dovessero anche sfruttare le caratteristiche di Full
Access (utenti che sviluppino maschere o reports o che progettino db
relazionali non ne ho mai conosciuti comunque) credo possano ritenersi
responsabili delle loro azioni  ;-)
Che cancellino documenti word o excel "sensibili", formattino windows,
prendano a mazzate il pc, o importino le linked tables dei colleghi ... non
è un problema tuo!
Comunque, fatta questa premessa, se davvero vuoi rinunciare alle linked
tables e utilizzare ADO, puoi popolare (Access >= XP) maschere, listboxes e
comboboxes solo utilizzando l'oggetto <Recordset> ... a meno che tu non
utilizzi i files .ADP/E (ma parrebbe di no).
Con i Reports dovrai ricorrere ad archivi temporanei locali, perchè
l'assegnazione a Runtime di recordsets come recordsource non è prevista per
la reportistica
Ciao, Oscar

 ha scritto nel messaggio 
news:u7utf.23504$eD5.3...@twister2.libero.it...

Le Query Pass-through fanno proprio questo ma verso un database server tipo 
SQLServer.
Le tabelle collegate potresti anche nasconderle alla visualizzazione.
Da codice puoi creare una query temporanea...e altro.
Una domanda: perchè vuoi complicarti la vita?
Ciao, Carlo

 l'assegnazione a Runtime di recordsets come recordsource non č prevista 


 ha scritto nel messaggio 
news:43b6785b$0$1057$4faf...@reader2.news.tin.it...


 Opendatabase?
Beh, comunque il codice riportato sopra è DAO, diversamente da come avevi
prima specificato.
Se non ricordo male esiste la possibilità di specificare nell'origine SQL la
stringa di connessione al DB, senza avere quindi linked tables.
Baraldi e/o Costarella saranno più precisi su questo: personalmente non ho
mai sfruttato questa possibilità.
Ma resto perplesso sulla tua scelta, a mio avviso sbagliata nelle premesse
(gli utenti "usano" le applicazioni, quindi non c'è motivo che Full Access
risieda sui loro clients).
Ciao, Oscar

 Opendatabase?
passandogli un elenco valori.
--
a.cara

> ' Comitato è un oggetto Combolist


 Ciao, Oscar
Per tutto il resto concordo con Oscar come anche premesso da me....!
Ritengo che tu ti stia complicando la vita, ma forse è proprio dovuto
ad una anomala modalità di sviluppo.
Saluti


 ha scritto nel messaggio 
news:43b67af8$0$1058$4faf...@reader2.news.tin.it...


 :-), Renato.
Ciao Renato, ho risposto anche in coda ad Oscar Manfredini.
In ogni caso si evince che non usi la protezione a livello utente
poichè se il tuo MDE fosse protetto bene a livello utente e tu provassi
a fare quello che dici ti accorgeresti che non sarebbe possibile a
meno di non appoggiarsi al File MDW, ma a quel punto qualsiasi cosa
sarebbe inutile, il file MDW è discretamente sicuro.
Diciamo che non è anti_Hacker, ma c'è anche da dire che gli utenti
medi sono scarsi programmatori, e ti assicuro che accedere al file
MDW serve molta malizia, ma molta......!!!
Ti invito a fare qualche prova per constatare quanto ti ho detto, che
poi è un metodo usato da circa 10 anni...!
;-)


 ha scritto nel messaggio 
news:07d23e3a1512154fd1...@mygate.mailgate.org...


 ha scritto nel messaggio 
news:12379008d9b5aebc10...@mygate.mailgate.org...


 Server linkandosi con un nuovo file access al tuo client?
La protezione Utente del Client che sono certo tu non abbia
implementato.


 ha scritto nel messaggio 
news:c9dfbea316054bce59...@mygate.mailgate.org...


 Se è così ci provo subito...
Esatto, ma fai attenzione alle impostazioni, non è sempre facile
da intuire la modalità corretta.
Di fatto implementando la protezione si vietano le manovre
non previste per il profilo utente, e dato che con un Client
estrno ti collegheresti come ADMIN, basterà eliminare l'utente
ADMIN dagli Administrator e crearti un Utente con privilegi di ADMIN
dedicato.
Quindi dopo esserti creato il file MDW devi ripristinare il System.MDW
per evitare il fastidioso Login.
E' chiaro che diventa un pò complesso per la manutenzione.
Io contrariamente a molti(poi è opinabile) non distribuisco nemmeno
il file MDW poichè non lo ritengo sufficientemente sicuro, e mi limito
ad eliminare tutti i privilegi all'ADMIN, quindi creo uno User(Admin)
ma ripristinando il System.MDW chiunque apre il Client come ADMIN
non ha la possibilità di fare nulla.
Se devo manutenere il Client lo faccio a casa mia dove ho il file MDB
associato al file MDW(completo), modifico e ricompilo in MDE quindi
distribuisco.
La gestione User, se serve la faccio io all'interno.
Per quanto mi riguarda è molto più sicuro che distribuire un MDW
e dato che ormai ho standardizzato in questo modo la cosa proseguo.


 ha scritto nel messaggio 
news:bedf0c7d686b4f0f66...@mygate.mailgate.org...


 Mi scuso per la mia manifesta ignoranza ma cercherò di porvi rimedio asap.
In effetti non ci si capiva su concetto importante: Access è installato su
molti clients aziendali (a volte legalmente, più spesso senza licenza) per
la sua appartenenza al pacchetto Office Pro e superiori.
Ma è un errore sfruttare questa presenza come "naturale", per due ragioni:
1) Come accennato, spesso le licenze dei clients aziendali non sono in
regola e per sistemare è necessario spendere (10 Clients, dieci licenze di
Access).
2) Le versioni di Access in circolazione sono ormai molte, il livello di
compatibilità non è buono e a farne le spese sarebbe il fornitore (che
versione utilizzare per lo sviluppo? Che formato per il DataBase)
Per svincolarsi da questi problemi è necessario acquistare la versione DEV
per Access, che consente la distribuzione di un pacchetto Runtime in
esenzione da royaltees.
Le applicazioni basate su Access potranno essere eseguite dal "Runtime", ma
non modificate o altro (non esistono strumenti di amministrazione).
Dai pc degli utenti aziendali si potrà rimuovere l'inutile "Full Access" (a
meno che lo usino per sviluppare, ma è una situazione anomala) e risolvere
alla radice la faccenda che hai esposto.
Credo che sul mercato sia  reperibile solo la versione 2003:
http://www.microsoft.com/italy/msdn/prodotti/vstudio/officetools/sviluppo.ms
px
Ciao, Oscar

 questo fà parte delle esigenze personali....!
Non mi riferivo a ODBCDirect + SQLServer ma a normalissimi .mdb.
Anche sulla tua area dovrebbero esserci esempi di stringhe SQL con stringa
di connessione a DB esterni... è una tecnica che si dovrebbe poter
utilizzare anche per maschere, reports, combo etc.
No?
Ciao, Oscar


cut
Questo un esempio per alimentare una maschera con una tabella non lincata...
Private Sub Form_Open(Cancel As Integer)
Dim db As Database, rcs As Recordset
Dim rcs2 As Recordset
Dim i As Long
Set db = OpenDatabase("c:\AbiCab.mdb")
Set rcs = db.OpenRecordset("ABi")
Set rcs2 = CurrentDb.OpenRecordset("SQAbi")
DoCmd.SetWarnings False
DoCmd.RunSQL "Delete * from SQAbi;"
DoCmd.SetWarnings True
For i = 1 To rcs.RecordCount
With rcs2
.AddNew
!ID = rcs!ID
!Abi = rcs!Abi
![Descrizione] = rcs![Descrizione]
!Data = rcs!Data
.Update
End With
rcs.MoveNext
Next i
rcs.Close
Set db = Nothing
rcs2.Close
Set rcs2 = Nothing
Me.RecordSource = "SQAbi"
End Sub
Lo stesso potrai fare per alimentare una combo.
SQAbi è una tabella temporanea con gli stessi campi della tabella da 
"importare".
L'utilizzo di tabelle temporanee non ti consentirà di modificare i dati 
nella tabella di origine...ovviamente.
In alternativa potresti lincare "al volo" la tabella per poi distuggerla 
quando vuoi:
Private Sub AllegaTabella()
DoCmd.TransferDatabase acLink, "Microsoft Access", "c:\AbiCab.mdb", acTable, 
"ABI", "ABI", False
End Sub
Private Sub EliminaTabella()
DoCmd.SetWarnings False
DoCmd.DeleteObject acTable, "ABI"
DoCmd.SetWarnings True
End Sub
Ciao, Carlo

 ha scritto nel messaggio 
news:43b7df52$0$1089$4faf...@reader1.news.tin.it...
