저는 작업 주문 관리를 위해 Access 기반 데이터베이스를 사용하는 소규모 기업에서 일하고 있습니다. 이 시스템은 수년간 사용되어 왔으며 데이터베이스에 액세스하기 위해 ISV의 맞춤형 소프트웨어를 사용하는 6~7대의 PC를 보유하고 있습니다. 데이터베이스는 매핑된 드라이브(Z:) 연결을 통해 액세스됩니다.
몇 달 전부터 간헐적으로 다음 오류가 발생하기 시작했습니다.
데이터 소스 이름을 찾을 수 없으며 기본 드라이버가 지정되지 않았습니다.
이로 인해 ISV는 데이터베이스를 복구하기 위해 데이터베이스에 연결하고 복구를 실행해야 합니다. 그들이 보는 오류는 좀 더 구체적이며 파일 형식이 손상되었음을 나타냅니다. 지원 기술에서는 네트워크 전반에 걸친 트랜잭션 실패로 인해 문제가 발생했다고 제안합니다. 이를 위해 우리는 여러 가지를 시도했습니다.
- 원래 "서버" PC에 문제가 있는 경우 데이터베이스를 다른 호스트로 옮겼습니다.
- 네트워크 스위치를 교체했습니다
- 일관된 결과 없이 문제 아동을 격리하기 위해 클라이언트를 네트워크에서 하나씩 제거하기 시작했습니다.
지금까지는 행운이 없습니다.
내 질문 - PC 중 하나가 드라이브 매핑을 닫고 열려 있는 데이터베이스를 손상시킬 수 있습니까? - Windows 7에 방해가 될 수 있는 새로운 것이 있습니까? - 원인을 파악하기 위한 더 나은 접근 방식을 권장할 수 있습니까?
답변1
이는 거의 확실하게 32비트와 64비트 DSN 문제입니다. 64비트 환경에서 32비트 DSN을 사용하려면 다음으로 이동하십시오.C:\Windows\SysWoW64\odbcad32.exe
내부 애플리케이션에도 매우 유사한 제한 사항이 있습니다. 향후 문제를 방지하려면 최신 버전을 설치하는 것이 좋습니다.SQL Server 네이티브 클라이언트그룹 정책을 통해 모든 컴퓨터에 32비트 및 64비트 DSN을 모두 배포합니다.
답변2
"NET USE" 대신 SUBST.exe 명령을 사용하여 드라이브를 매핑하는 경우 "NET USE"와 달리 매핑된 드라이브가 손실되면 연결이 항상 다시 시도됩니다. 이 방법을 사용하면 SUBST.exe 명령에 대해 모르는 사람이 드라이브 매핑을 해제하기가 어렵다는 점을 명심하세요. 드라이브가 이런 방식으로 매핑되면 Windows Explorer에서 연결을 끊을 수 없습니다. 작동하지 않습니다.
개인적으로는 64비트 문제라는 점에 동의합니다.
32비트 및 64비트 ODBC DSN 제어판은 특정 방식으로 작동할 것으로 예상되지만 어떤 경우에는 그 반대일 수도 있습니다. 예를 들어, 64비트 시스템에서 64비트 "사용자 DSN"을 추가하려고 하면 연결이 실패하지만 "시스템 DSN"을 사용하면 연결이 작동한다는 것을 알 수 있습니다. 이는 ODBC 패널이 실제로 64비트 ODBC 제어판의 "사용자" 탭에서 "32비트 DSN"을 생성하는 반면 "시스템" 탭에서는 예상되는 64비트 DSN을 생성하기 때문입니다. 제어판이 예상대로 작동하지 않을 가능성을 알고 있는 한 어떤 구성도 문제가 되지 않을 것이라고 생각합니다.