다중 사용자 액세스 프런트 엔드를 SQL Server 백 엔드에 연결

Question

항상 감사드립니다.

~ 100 명의 최종 사용자에게 배포 할 Access 데이터베이스를 구축했습니다. 현재 5 명의 사용자를 대상으로 파일럿 프로그램을 운영 중입니다. 테이블을 SQL 2014 Server로 마이그레이션했지만 현재 파일럿 프로그램의 백 엔드는 공유 네트워크 폴더 (해당 위치를 모르는 위치)에 있습니다. 필자는 공유 네트워크에 파일을 저장하고 최종 사용자에게 복사본을 바탕 화면에 저장하도록 지시하여 액세스 프런트 엔드 (accde 파일 형식)를 배포했습니다. 조종사는 조금 느리지 만 괜찮습니다. 나는 내 컴퓨터에 ODBC 연결을 설정할 수 있어요, 그 연결을 통해 SQL 서버 백엔드에 연결할 수 있어요

: 나는 데

문제는 이것이다. 그러나 최종 사용자가 서버의 테이블에 액세스하는 방법을 모르겠습니다. 서버의 각 사용자에 대한 사용자 이름을 만들고 읽기 및 쓰기 권한을 부여해야합니까? 또한 프런트 엔드를 설치할 각 컴퓨터에 ODBC 연결을 만들어야합니까? 각 컴퓨터에서 ODBC 연결을 만들 필요가 없다면이 문제를 해결할 수 있습니까? 고맙습니다!

액세스 버전 : 2013 SQL : 2014 SSMS 2014

- 찰리

Answer 1

에서 작업 당신은 모든 컴퓨터에 ODBC 연결이 필요하지 않습니다. DoCmd.TransferDatabase을 통해 ODBC 연결 문자열을 사용하여 연결을 만들 수 있습니다. 이것은 영구적이므로 프론트 엔드의 개발 사본에서 연결/업데이트를 실행할 수 있으며 연결은 존재하며 사용자가 작성한 최종 사용자 사본에 계속 유지됩니다.

인증 문제를 처리해야합니다. 보안 상황에 따라 단일 "데이터베이스 사용자"를 만들고 위 연결에 사용자 이름과 암호를 포함시킬 수 있습니다. 광고 환경에 있다면 인증을 위해 사용할 수 있습니다. 또는 각 사용자 또는 사용자 그룹에 대해 개별 SQL 계정을 만듭니다. 액세스 권한이 사용자에게 읽기/쓰기 권한이있는 경우 사용자가 수행 한 작업에 관계없이 테이블을보고 편집 할 수 있습니다. 보기를 사용하여 테이블 자체 대신 액세스에 링크하는 방식으로 개별 테이블을 보호 할 수 있습니다.

사용자가 프런트 엔드의 로컬 복사본을 만들지 않도록하는 것이 좋습니다. 이로 인해 사용자가 최신 버전의 프런트 엔드를 사용하고 있는지 확인하는 것이 어려워집니다. 대신 그들이 바로 가기를 만들도록 권장하십시오. 사용자 당 로컬 임시 테이블이나 양식/보고서를 동적으로 편집하는 코드가없는 한 모든 사람이 동일한 프런트 엔드 파일을 사용하지 않아도되는 많은 이유는 없습니다. 이 경우에도 각 사용자의 프론트 엔드 사본을 작성/겹쳐 쓰는 배치 배치 파일을 작성하십시오. SQL 서버 데이터베이스에 연결

샘플 코드 :

Public Sub LoadDatabase() 

Dim MyDB As DAO.Database 
Set MyDB = CurrentDb 
Dim d As DAO.Recordset 
Set d = MyDB.OpenRecordset("SELECT TableName FROM tblLinkTables") 
d.MoveFirst 
Do While Not d.EOF 
    DoCmd.DeleteObject acTable, d!TableName 
    DoCmd.TransferDatabase acLink, "ODBC Database", "ODBC;Driver={SQL Server};Server=MYSQLSERVERNAME;Database=MyDatabaseName;Uid=DatabaseUser;Pwd=DatabaseUserPassword", acTable, d!TableName, d!TableName, False, True 
    d.MoveNext 
    Loop 
d.Close 
Set d = Nothing 

End Sub 

링크 테이블 목록이 각 테이블을 연결하는 데 사용할위한 하나의 필드 TABLENAME와 tblLinkTables라는 로컬 테이블에 존재합니다. 이것은 매우 단순화 된 버전입니다. 내가 실제로 사용하는 것은 SQL 테이블과 다른 로컬 테이블 이름을 가지며보기를 연결하고 기본 키를 생성 할 수 있습니다 (선택 사항).

Answer 2

다음은 SQL Server에 연결하는 방법의 한 예입니다. Windows 사용자가 액세스 권한을 부여 받거나 sqlserver에 정의 된 사용자 ID와 암호를 지정할 수있는 신뢰할 수있는 연결 (Trusted Connection) 사용을 지원합니다.

' The following are some of the parameters the connection will use. 
Global gv_DBS_SQLServer     As ADODB.Connection 
Global gvstr_SQLServer_Name    As String 
Global gv_SQLServer_DSN     As String 
Global gvstr_SQLServer_Database   As String 

'Call the GetConnection Function 
' Pass Name of Server; Database Name; Connection Variable; adUseServer; True if using Password; False if not using a Trusted Connection; 
' Sample 
    If GetConnection(gvstr_SQLServer_Name, gvstr_SQLServer_Database, _ 
      gv_DBS_SQLServer, adUseServer, True, False) = False Then 
     MsgBox "Unable to connect to SQL Server", vbOKOnly, "No Connection" 
    End If 


Public Function GetConnection(ByVal strDSN As String, _ 
     ByVal strDatabase As String, _ 
     ByRef cnLocal As ADODB.Connection, _ 
     ByVal CursorLoc As CursorLocationEnum, _ 
     ByVal UsePassword As Boolean, _ 
     ByVal blnTrusted As Boolean) As Boolean 

Dim strConnectString As String 
Dim strDisplay   As String 

    On Error GoTo ERROR_HANDLER 
    GetConnection = False 
Retry_Connection: 
    If cnLocal Is Nothing Then Set cnLocal = New ADODB.Connection 
    If cnLocal.State = adStateOpen Then 
     Debug.Print "Connection already open -- -will not reopen!!" 
     GetConnection = True 
     GoTo Proc_Exit 
    End If 
    With cnLocal 
     Debug.Print "Use TRUSTED CONNECTION (ABOVE)" 
     If blnTrusted = True Then 
      strConnectString = "Driver={SQL Server};" & _ 
           "Server=" & strDSN & ";" & _ 
           "Database=" & strDatabase & ";" & _ 
           "Trusted_Connection=yes" 
     Else 
      strConnectString = "Driver={SQL Server};" & _ 
           "Server=" & strDSN & ";" & _ 
           "Database=" & strDatabase & ";" & _ 
           "User Id=UUUUUUU;Password=" & DecryptString("PPPPPPPP") & "" 

      strDisplay = "Driver={SQL Server};" & _ 
         "Server=" & strDSN & ";" & _ 
         "Database=" & strDatabase & ";" & _ 
         "User Id=UUUUUU;Password=PPPPPPP" 

     End If 

     Debug.Print "Will use Conn String: " & strDisplay 
     .ConnectionString = strConnectString 
     .CursorLocation = CursorLoc 
     .Open 
    End With 
    GetConnection = True 
Proc_Exit: 
    Exit Function 
ERROR_HANDLER: 
    Debug.Print Err.Number & vbCrLf & Err.Description 
    Err.Source = "Module_Connect: " 
    DocAndShowError 
    Resume Proc_Exit 
    Resume Next 
    Resume 
End Function 

Answer 3

몇 가지 : - 다음 ODBC 데이터베이스

당신은 단순히 리본 가져 오기 및 링크를 사용하여 연결된 테이블을 만들 때. 파일 DSN을 선택하기 만하면됩니다. 그 이유는 DEFAULT에 의한 액세스는 DSN-less 연결을 사용하기 때문입니다. 간단히 말하자면 테이블을 연결할 때 이것은 각 워크 스테이션에 applcatation을 배포 할 수 있으므로 SYSTEM/Machine DSN을 설정할 필요가 없습니다.

기본 파일 DSN을 사용하십시오. Access에서 SQL Server에 대한 링크를 생성하면 이러한 링크는 DSN이 적기 때문에 각 워크 스테이션마다 별도의 설정이 필요하지 않습니다.

SQL 서버에 사용자를 생성하는 방법은 무엇입니까? 음, 각 사용자에 대해 특별한 보안을 원한다면 필요하지 않을 수도 있습니다. SQL 로그온을 사용하는 경우 위의 링크 과정에서 암호 저장 옵션을 "확인"하십시오. 다시 한번 말하면, 기본적으로 링크 된 테이블은 DSN이 없으므로 모든 사용자는 사실 하나의 동일한 SQL 사용자/암호를 사용하므로 각 사용자에게 투명합니다 (로그온 할 필요가 없습니다).

SQL 로그온에 Windows 인증을 사용하는 경우 보안은 SQL Server가 아닌 Windows 시스템으로 설정됩니다. 이 경우 각 사용자 Windows 로그온은 SQL Server의 사용을 제어 (사용)하는 데 사용됩니다. 도메인 컨트롤러를 사용하지 않는다면 SQL 로그온을 사용하고있을 가능성이 높습니다. SQL 서버에 대한 각 로그온 및 권한에 대해 IT 관리자를 호출하고 싶지 않기 때문에 기업 환경에서조차도 SQL 로그온을 선택해야합니다. 따라서 IT 관리자가 SQL 서버에 대한 충분한 권한을 "한 번"갖게되면 모든 사용자에게 "하나의 동일한 로그온"을 사용하여 자유롭게 자신의 로그온을 만들 수 있으므로 IT를 괴롭히는 데 시간을 낭비 할 필요가 없습니다 여러분.

몇 가지 추가 최종 점 : 모든 종류의 ADO 및 VBA 코드와 연결 문자열 등을 사용하는 것을 무시합니다. 필요하지 않습니다. 실제로 대부분의 경우 응용 프로그램에서 ADO 코드를 피하려고합니다. 그리고 oleDB는 SQL 서버 (ADO가 의존하는 경향이 있음)에 대해 가치가 떨어집니다.

당신은 여전히 ​​각 워크 스테이션에있는 프런트 엔드 프로그램을 배치하고 싶습니다. 각 워크 스테이션 또는 회계 패키지에 단어를 설치하는 것처럼 소프트웨어를 개발하고 있으므로 지난 30 년간 IT 산업과 같은 각 워크 스테이션에 소프트웨어를 설치하십시오. 공유 폴더에있는 데이터를 확실히 공유 할 수 있지만 실제 응용 프로그램 (단어, Excel 또는이 경우 각 워크 스테이션에 appletation을 설치합니다.)을 배포하기 전에 accDB로 컴파일해야합니다.

이러한 사용자에 대한 배포가 동일한 네트워크에있는 경우 SQL 서버에 "연결"또는 "연결"하기 위해 시작할 때 특별한 코드가 실제로 필요하지 않습니다. 개발자 또는 컨설턴트가 "오프 사이트"인 경우 추가 할 필요가 있습니다 일부 코드는 SQL 서버에 다시 연결하여 오프 사이트에서 개발하는 것보다 틀릴 것입니다. 그래서 "다른"SQL 서버에 다시 링크 할 수있는 능력이 있어야합니다. 현장에서 개발할 수 없거나 작업중인 SQL 서버가 사용중인 실제 프로덕션 SQL 서버의 "복사"또는 "테스트"버전 인 경우 필요합니다.