Access nói chuyện với các nguồn dữ liệu ODBC như thế nào? Phần 5

Lọc tập bản ghi

Trong phần 5 của loạt bài này, chúng ta sẽ tìm hiểu cách Microsoft Access xử lý các bộ lọc đã triển khai và tích hợp chúng vào các truy vấn ODBC. Trong bài viết trước, chúng ta đã biết cách Access sẽ hình thành SELECT các câu lệnh trong lệnh ODBC SQL. Chúng ta cũng đã biết trong bài viết trước về cách Access sẽ cố gắng cập nhật một hàng bằng cách áp dụng WHERE mệnh đề dựa trên khóa và nếu có, đảo ngược. Tuy nhiên, chúng ta cần tìm hiểu cách Access sẽ xử lý các bộ lọc được cung cấp cho các truy vấn Access và dịch chúng trong lớp ODBC. Có các cách tiếp cận khác nhau mà Access có thể sử dụng tùy thuộc vào cách các truy vấn Access được xây dựng và bạn sẽ học cách dự đoán cách Access sẽ dịch một truy vấn Access thành một truy vấn ODBC cho các vị từ bộ lọc khác nhau đã cho.

Bất kể bạn thực sự áp dụng bộ lọc như thế nào - có thể là tương tác thông qua các lệnh ruy-băng của biểu mẫu hoặc biểu dữ liệu hoặc nhấp chuột vào menu bên phải, hoặc sử dụng VBA theo chương trình hoặc chạy các truy vấn đã lưu - Access sẽ đưa ra một truy vấn ODBC SQL tương ứng để thực hiện lọc. Nói chung, Access sẽ cố gắng lọc từ xa nhiều nhất có thể. Tuy nhiên, nó sẽ không cho bạn biết nếu nó không thể làm như vậy. Thay vào đó, nếu Access không thể thể hiện bộ lọc bằng cú pháp ODBC SQL, thay vào đó, nó sẽ cố gắng tự thực hiện lọc bằng cách tải xuống toàn bộ nội dung của bảng và đánh giá điều kiện cục bộ. Điều đó có thể giải thích tại sao đôi khi bạn có thể gặp phải một truy vấn chạy nhanh nhưng chỉ với một thay đổi nhỏ, việc thu thập thông tin lại bị chậm lại. Phần này hy vọng sẽ giúp bạn hiểu khi nào điều này có thể xảy ra và cách xử lý để bạn có thể giúp Access từ xa càng nhiều càng tốt vào các nguồn dữ liệu để áp dụng bộ lọc.

Đối với bài viết này, chúng tôi sẽ sử dụng các truy vấn đã lưu nhưng thông tin thảo luận ở đây vẫn sẽ áp dụng cho các phương pháp áp dụng bộ lọc khác.

Bộ lọc tĩnh

Chúng tôi sẽ bắt đầu dễ dàng và tạo một truy vấn đã lưu bằng bộ lọc được mã hóa cứng.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName="Boston";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Bộ lọc được tham số hóa đơn giản

Hãy thay đổi SQL để sử dụng một tham số thay thế:

PARAMETERS SelectedCityName Text ( 255 );
SELECT 
  c.CityID
 ,c.CityName
 ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[SelectedCityName];

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" =  ? ) 

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName=[Forms]![frmSomeForm]![txtSomeText];

Điều đó cũng hoạt động cho chức năng VBA. Chúng ta có thể thêm một hàm VBA mới:

Public Function GetSelectedCity() As String
    GetSelectedCity = "Boston"
End Function

WHERE c.CityName=GetSelectedCity();

Tuy nhiên, có một kịch bản phổ biến hơn mà các nhà phát triển Access thường thiết lập và đó là tạo SQL động với mã VBA, thường bằng cách nối một chuỗi và sau đó thực thi chuỗi đã nối. Hãy sử dụng mã VBA sau:

Public Sub GetSelectedCities()
    Dim db As DAO.Database
    Dim rs As DAO.Recordset
    Dim fld As DAO.Field
    
    Dim SelectedCity As String
    Dim SQLStatement As String
    
    SelectedCity = InputBox("Enter a city name")
    SQLStatement = _
        "SELECT c.CityID, c.CityName, c.StateProvinceID " & _
        "FROM Cities AS c " & _
        "WHERE c.CityName = '" & SelectedCity & "';"
    
    Set db = CurrentDb
    Set rs = db.OpenRecordset(SQLStatement)
    Do Until rs.EOF
        For Each fld In rs.Fields
            Debug.Print fld.Value;
        Next
        Debug.Print
        rs.MoveNext
    Loop
End Sub

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" = 'Boston' ) 

Vì lý do đó, các truy vấn được tham số hóa từ Access chống lại các nguồn ODBC có thể được ưu tiên hơn so với SQL động. Vì Access sẽ coi các điều khiển tham chiếu trên biểu mẫu hoặc các hàm VBA không yêu cầu tham chiếu cột làm tham số, bạn không cần tham số rõ ràng trong nguồn bản ghi hoặc nguồn hàng của mình. Tuy nhiên, nếu bạn đang sử dụng VBA để thực thi SQL, thông thường tốt hơn là sử dụng ADO, hỗ trợ tốt hơn nhiều cho việc tham số hóa. Trong trường hợp tạo nguồn bản ghi động hoặc nguồn hàng, sử dụng điều khiển ẩn trên biểu mẫu / báo cáo có thể là một cách dễ dàng để tham số hóa truy vấn. Tuy nhiên, nếu truy vấn có sự khác biệt rõ rệt, việc xây dựng SQL động trong VBA và gán nó cho thuộc tính nguồn bản ghi / nguồn hàng có hiệu quả buộc phải biên dịch lại đầy đủ và do đó tránh sử dụng các kế hoạch thực thi không tốt sẽ không hoạt động tốt cho tập hợp đầu vào hiện tại. Bạn có thể tìm thấy các đề xuất trong bài viết thảo luận về WITH RECOMPILE của SQL Server hữu ích trong việc quyết định có buộc biên dịch lại hay không sử dụng truy vấn được tham số hóa.

Sử dụng các hàm trong lọc SQL

Trong phần trước, chúng ta đã thấy rằng một câu lệnh SQL chứa hàm VBA được tham số hóa để Access có thể thực thi hàm VBA và sử dụng đầu ra làm đầu vào cho truy vấn được tham số hóa. Tuy nhiên, không phải tất cả các hàm tích hợp đều hoạt động theo cách này. Hãy sử dụng UCase() làm ví dụ để lọc truy vấn. Hơn nữa, chúng tôi sẽ áp dụng hàm trên một cột.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE UCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT "c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ({fn ucase("CityName" )}= 'BOSTON' )

Nếu sau đó chúng ta tạo một hàm VBA tùy chỉnh mô phỏng UCase() chức năng:

Public Function MyUCase(InputValue As Variant) As String
    MyUCase = UCase(InputValue)
End Function

WHERE MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 

Mặc dù chúng tôi đã sử dụng UCase() trong ví dụ này, rõ ràng chúng ta có thể thấy rằng tốt hơn hết là làm việc từ xa càng nhiều càng tốt với nguồn dữ liệu. Nhưng điều gì sẽ xảy ra nếu chúng ta có một hàm VBA phức tạp không thể viết lại thành phương ngữ SQL gốc của nguồn dữ liệu? Mặc dù tôi nghĩ rằng trường hợp này khá hiếm, nhưng nó đáng để xem xét. Giả sử rằng chúng ta có thể thêm một bộ lọc để thu hẹp tập hợp các thành phố được trả lại.

SELECT 
   c.CityID
  ,c.CityName
  ,c.StateProvinceID
FROM Cities AS c
WHERE c.CityName LIKE "Bos*"
  AND MyUCase([c].[CityName])="BOSTON";

SQLExecDirect: 
SELECT 
   "CityName"
  ,"c"."CityID" 
FROM "Application"."Cities" "c" 
WHERE ("CityName" LIKE 'Bos%' ) 

Điều này cho chúng ta biết nếu chúng ta phải đối mặt với tình huống không mong muốn trong đó chúng ta không thể dễ dàng cấu trúc lại một hàm VBA phức tạp từ một truy vấn, chúng ta vẫn có thể giảm thiểu các tác động xấu bằng cách thêm các bộ lọc có thể được điều khiển từ xa để giảm tập hợp các bản ghi ban đầu để Access làm việc với.

Lưu ý về khả năng phân loại

Trong các ví dụ trước, chúng tôi đã áp dụng một hàm vô hướng trên một cột. Điều đó có khả năng hiển thị truy vấn là "không phân chia được", có nghĩa là công cụ cơ sở dữ liệu không thể tối ưu hóa truy vấn bằng cách sử dụng chỉ mục để tìm kiếm và tìm các kết quả phù hợp. Phần “sarg” của từ “sargability” đề cập đến “Search ARGument”. Giả sử chúng ta có chỉ mục được xác định tại nguồn dữ liệu trên bảng:

CREATE INDEX IX_Cities_CityName
ON Application.Cities (CityName);

CREATE INDEX IX_Cities_Boston_Uppercase
ON Application.Cities (CityName)
WHERE UCASE(CityName) = 'BOSTON';

Bất kể công cụ cơ sở dữ liệu nào bạn đang thực sự làm việc, bạn luôn nên thiết kế và sử dụng các truy vấn có thể phân loại ở bất kỳ nơi nào có thể để tránh các vấn đề về hiệu suất. Các truy vấn quan trọng phải có các chỉ số bao trùm để mang lại hiệu suất tốt nhất. Tôi khuyến khích bạn nghiên cứu thêm về khả năng phân loại và các chỉ số bao hàm để giúp bạn tránh thiết kế các truy vấn trên thực tế là không thể phân loại.

Kết luận

Chúng tôi đã xem xét cách Access xử lý việc áp dụng bộ lọc từ Access SQL vào các truy vấn ODBC. Chúng tôi cũng đã khám phá các trường hợp khác nhau trong đó Access sẽ chuyển đổi các loại tham chiếu khác nhau thành một tham số, cho phép Access thực hiện đánh giá bên ngoài lớp ODBC và chuyển chúng dưới dạng đầu vào vào câu lệnh ODBC đã chuẩn bị. Chúng tôi cũng đã xem xét điều gì sẽ xảy ra khi nó không thể được tham số hóa, thường là do chứa các tham chiếu cột làm đầu vào. Điều đó có thể gây ra hậu quả về hiệu suất trong quá trình di chuyển sang máy chủ SQL.

Đối với một số hàm nhất định, Access có thể chuyển đổi biểu thức để sử dụng các hàm vô hướng ODBC, điều này cho phép Access điều khiển biểu thức từ xa tới nguồn dữ liệu ODBC. Một phân nhánh của điều này là nếu việc triển khai hàm vô hướng khác nhau, nó có thể khiến truy vấn hoạt động khác hoặc có thể hoạt động nhanh hơn / chậm hơn. Chúng tôi đã thấy cách một hàm VBA, ngay cả một hàm đơn giản bao bọc một hàm vô hướng có thể điều khiển từ xa khác có thể đánh bại nỗ lực điều khiển biểu thức từ xa. Chúng tôi cũng biết rằng nếu chúng tôi gặp trường hợp không thể cấu trúc lại một hàm VBA phức tạp từ truy vấn Access / nguồn ghi / nguồn hàng, thì ít nhất chúng tôi có thể giảm thiểu việc tải xuống tốn kém bằng cách thêm các bộ lọc bổ sung trên truy vấn có thể được khởi động từ xa để giảm số lượng dữ liệu được trả về.

Trong bài tiếp theo, chúng ta sẽ xem xét cách Access xử lý các phép nối.

Tìm kiếm trợ giúp với Microsoft Access? Gọi cho các chuyên gia của chúng tôi ngay hôm nay theo số 773-809-5456 hoặc gửi email cho chúng tôi theo địa chỉ [email protected].