Come posso ottenere ms-access per connettermi a ms-sql come utente diverso?

Question

Come posso ottenere l'accesso ms per connettermi (tramite ODBC) a un database ms-sql come utente diverso rispetto al proprio ID Active Directory?

Non voglio specificare un account nella connessione ODBC, voglio farlo sul lato ms-access per nasconderlo ai miei utenti.Farlo nella connessione ODBC mi riporterebbe alla situazione originale che sto cercando di evitare.

Sì, questo si riferisce a una domanda precedente: http://www.stackoverflow.com/questions/50164/

Answer 1

Penso che puoi farlo funzionare nel modo desiderato se usi un file "Connessione ODBC DSN-LESS"

Se necessario, mantieni i tuoi DSN ODBC sui computer dei tuoi utenti utilizzando l'autenticazione di Windows.Concedi ai tuoi utenti l'accesso in sola lettura al tuo database.(Se creano un nuovo file mdb e collegano le tabelle, potranno solo leggere i dati.)

Crea un accesso SQL con autorizzazione di lettura/scrittura sul tuo database.

Scrivi una routine VBA che esegue il loop sulle tabelle collegate e reimposta la connessione per utilizzare l'accesso SQL, ma assicurati di utilizzare la sintassi "DSN-Less".

"ODBC;Driver={SQL Native Client};" &
       "Server=MyServerName;" & _
       "Database=myDatabaseName;" & _
       "Uid=myUsername;" & _
       "Pwd=myPassword"

Chiama questa routine come parte del tuo codice di avvio.

Un paio di note su questo approccio:

• L'accesso sembra avere un problema con le informazioni di connessione una volta che si passa da Lettura/Scrittura a Sola lettura e si prova a tornare a Lettura/Scrittura senza chiudere e riaprire il file del database (mde/mdb).Se puoi modificarlo una volta all'avvio in Lettura/Scrittura e non modificarlo durante la sessione, questa soluzione dovrebbe funzionare.

• Utilizzando una connessione DSN - Less puoi nascondere le credenziali all'utente nel codice (supponendo che tu stia dando loro un file mde, dovresti essere a posto).Normalmente le stringhe di connessione codificate non sono una buona idea, ma poiché hai a che fare con un'app interna dovresti essere d'accordo con questo approccio.

Answer 2

Penso che dovresti avviare il processo MS Access con l'account che desideri utilizzare per connetterti.Esistono vari strumenti che ti consentono di farlo, ad esempio CPAU.Questo strumento ti consentirà anche di crittografare la password.

Answer 3

Ammettiamo qui che stai utilizzando una connessione ODBC al tuo database con la Sicurezza Integrata attiva, quindi non devi/non vuoi scrivere un valore nome utente/password nella stringa di connessione (che secondo me è la scelta giusta).

In questo caso fortunatamente non c'è modo di "simulare" un altro utente durante la connessione ai dati.Ammetti con me che riuscire a realizzare una cosa del genere rappresenterebbe un enorme passo avanti nella sicurezza integrata!

Ho capito dal tuo post precedente che volevi che gli utenti fossero in grado di aggiornare o meno i dati a seconda dell'interfaccia client che utilizzano.Secondo me l'idea sarebbe quella di creare per ogni tabella una vista collegata "non aggiornabile".Diciamo che per ogni tabella chiamata Table_Blablabla crei una vista (=query in Access) chiamata View_Table_Blablabla ...).

Quando si utilizza Access è possibile decidere in fase di runtime se si desidera aprire la tabella aggiornabile o la visualizzazione di sola lettura.Questo può essere fatto ad esempio in fase di runtime, nel file form_Open evento, impostando il modulo recordsource sulla tabella o sulla vista.

Answer 4

@Filippo
Presumo che tu stia usando la parola ammettere come approssimativamente equivalente a capire o forse Essere d'accordo;al contrario del contrario di negare.

Comprendo le implicazioni di avere tutti gli utenti che accedono al database utilizzando un ID e una password (e di averli archiviati nell'applicazione).Questo per me è un rischio minore rispetto al problema che sto affrontando in questo momento.
@spento

Ulteriori informazioni sul problema:Ho configurato connessioni ODBC su ciascuna delle workstation degli utenti utilizzando l'autenticazione Windwos NT.Nella maggior parte dei casi gli utenti si connettono utilizzando una configurazione MDE per utilizzare la connessione ODBC: in questo caso hanno SEMPRE la possibilità di aggiungere/aggiornare/eliminare dati.

Il problema nasce dal fatto che alcuni utenti sono sufficientemente istruiti su MS-Access per creare un nuovo mdb e collegarlo al server MS-SQL.Possono quindi modificare i dati direttamente all'interno delle tabelle anziché passare attraverso l'applicazione che esegue una certa quantità di convalida e controllo.E loro Piace facendo questo, ma a volte rovina tutto e mi causa problemi.

Answer 5

Quello che speravo di fare (cosa che ho appena sperimentato) era aggiornare i collegamenti al database in modo simile a questo per ogni tabella (Nota:Per questo esperimento ho cambiato la connessione ODCB con l'autenticazione SQL Server e ho aggiunto anche gli account al server SQL: sola lettura - che non può essere aggiornato, e leggere scrivere - che ha pieni privilegi sul tavolo).

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readonly;" & _
                "PWD=readonly_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

questo impedisce loro di modificare, ma non riesco a far funzionare una riscrittura successiva

myTable.Connect = _
                "ODBC;" & _
                "DATABASE=" & "MyTestDB" & ";" & _
                "UID=readwrite;" & _
                "PWD=readwrite_password;" & _
                "DSN=" & "MyTestDB" & ";"
myTable.RefreshLink

Sembra che qualunque sia il permesso a cui mi connetto per primo, rimanga permanentemente.Se avvio la lettura e poi vado in sola lettura, la tabella rimane con i privilegi di lettura

Answer 6

Perché non utilizzare la sicurezza integrata/di Windows.Puoi concedere a un gruppo di Active Directory i diritti che desideri per gli utenti e quindi aggiungere gli account utente a quel gruppo.Credo che tu possa anche utilizzare la funzionalità dei ruoli di SQL Server in aggiunta a questa per limitare la funzionalità in base all'applicazione client utilizzata.