CẬP NHẬT: Đã thêm một số giải thích rõ hơn về ý nghĩa của SQLExecute và cách Access đang xử lý các truy vấn đã chuẩn bị. Cảm ơn, Bob!
Access đang làm gì khi chúng tôi duyệt và xem các bản ghi trong bảng được liên kết ODBC?
Trong phần thứ hai của loạt bài theo dõi ODBC, trọng tâm của chúng ta sẽ chuyển sang tác động của các loại tập bản ghi trong bảng được liên kết ODBC. Trong bài trước, chúng ta đã học cách bật ODBC SQL trace và bây giờ chúng ta có thể xem kết quả. Nếu bạn đã chơi với nó một chút, bạn có thể nhận thấy rằng truy vấn Access của bạn và câu lệnh ODBC SQL mà Access tạo ra trông không giống nhau lắm. Chúng tôi cũng sẽ cung cấp một cái nhìn chuyên sâu về cách các kiểu ảnh hưởng đến hành vi của các truy vấn CHỌN và chúng tôi cũng sẽ xem xét các biến thể khác nhau của các tập bản ghi như Ảnh chụp nhanh và Tập động tác.
Nếu muốn theo dõi, bạn có thể sử dụng cơ sở dữ liệu mẫu được cung cấp tại đây.
Ảnh hưởng của các loại Tập bản ghi trong truy vấn CHỌN
Các loại tập bản ghi có ảnh hưởng lớn đến cách Access sẽ giao tiếp với các nguồn dữ liệu ODBC. Bạn có thể nhận thấy rằng trong dạng xem thiết kế biểu mẫu hoặc dạng xem thiết kế truy vấn, bạn có thể đặt loại tập bản ghi. Theo mặc định, nó được đặt thành Dynaset .
Trong VBA, chúng tôi có thêm một số tùy chọn nhưng hiện tại chúng tôi sẽ không lo lắng về điều đó. Hãy bắt đầu với việc hiểu chính xác Dynaset là gì và Snapshot có nghĩa là đầu tiên. Chúng tôi sẽ bắt đầu với loại ít được sử dụng hơn, Snapshot đầu tiên.
Bộ ghi loại ảnh chụp nhanh
Snapshot là khá đơn giản. Về cơ bản, điều đó có nghĩa là chúng tôi chụp nhanh kết quả tại thời điểm thực thi truy vấn. Thông thường, điều này cũng có nghĩa là Access không thể cập nhật kết quả. Tuy nhiên, hãy xem cách Access truy vấn nguồn bằng tập hợp bản ghi dựa trên ảnh chụp nhanh. Chúng tôi có thể tạo một truy vấn Access mới như vậy:
SQL như chúng ta có thể thấy trong chế độ xem SQL của truy vấn Access là:
SELECT Cities.* FROM Cities;Chúng tôi sẽ chạy truy vấn và sau đó xem xét
sqlout.txt tập tin. Đây là đầu ra, được định dạng để dễ đọc: SQLExecDirect: SELECT "CityID" ,"CityName" ,"StateProvinceID" ,"Location" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" FROM "Application"."Cities"Có một số khác biệt giữa những gì chúng tôi đã viết trong truy vấn của Access so với những gì Access đã gửi đến ODBC, chúng tôi sẽ phân tích.
- Access đã đủ điều kiện cho bảng có tên giản đồ. Rõ ràng, trong phương ngữ Access SQL, điều đó không hoạt động theo cùng một cách nhưng đối với phương ngữ ODBC SQL, sẽ rất hữu ích nếu đảm bảo rằng chúng tôi đang chọn từ bảng bên phải. Điều đó được điều chỉnh bởi
SourceTableNametài sản. - Access đã mở rộng nội dung của
Cities.*vào danh sách liệt kê tất cả các cột mà Access đã biết dựa trênFieldstập hợpTableDefbên dưới đối tượng. - Quyền truy cập đã sử dụng
"để trích dẫn các số nhận dạng, đó là điều mà phương ngữ ODBC SQL mong đợi. Mặc dù cả Access SQL và Transact-SQL đều sử dụng dấu ngoặc để trích dẫn một số nhận dạng, nhưng đó không phải là cú pháp hợp pháp trong phương ngữ ODBC SQL.
Vì vậy, mặc dù chúng tôi chỉ thực hiện một truy vấn ảnh chụp nhanh đơn giản chọn tất cả các cột cho một bảng, bạn có thể thấy rằng Access thực hiện nhiều chuyển đổi đối với SQL giữa những gì bạn đặt trong chế độ xem thiết kế truy vấn Access hoặc chế độ xem SQL so với những gì Access thực sự phát ra dữ liệu nguồn. Tuy nhiên, trong trường hợp này, nó chủ yếu là cú pháp nên không có sự khác biệt thực sự trong câu lệnh SQL giữa truy vấn Access ban đầu và câu lệnh ODBC SQL.
Dấu vết cũng được thêm SQLExecDirect ở đầu câu lệnh SQL. Chúng ta sẽ quay lại vấn đề đó sau khi chúng ta xem xét một số ví dụ khác.
Bộ bản ghi loại Dynaset
Chúng tôi sẽ sử dụng cùng một truy vấn nhưng thay đổi thuộc tính về mặc định, Dynaset .
Chạy lại và chúng tôi sẽ thấy những gì chúng tôi nhận được từ sqlout.txt . Một lần nữa, nó được định dạng để dễ đọc:
SQLExecDirect: SELECT "Application"."Cities"."CityID" FROM "Application"."Cities" SQLPrepare: SELECT "CityID" ,"CityName" ,"StateProvinceID" ,"Location" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" FROM "Application"."Cities" WHERE "CityID" = ? SQLExecute: (GOTO BOOKMARK) SQLPrepare: SELECT "CityID" ,"CityName" ,"StateProvinceID" ,"Location" ,"LatestRecordedPopulation" ,"LastEditedBy" ,"ValidFrom" ,"ValidTo" FROM "Application"."Cities" WHERE "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? OR "CityID" = ? SQLExecute: (MULTI-ROW FETCH) SQLExecute: (MULTI-ROW FETCH)Chà, rất nhiều thứ đang xảy ra! Đây chắc chắn là trò chuyện nhiều hơn so với bộ ghi kiểu ảnh chụp nhanh. Hãy xem xét từng cái một.
Người đầu tiên chỉ chọn CityID cột. Đó là khóa chính của bảng, nhưng quan trọng hơn, đó là chỉ mục mà Access đang sử dụng bên cạnh. Điều đó sẽ trở nên quan trọng khi chúng ta nghiên cứu các quan điểm sau này. Access sử dụng truy vấn này để lấy khóa và sử dụng truy vấn đó để điền vào các truy vấn khác sau này như chúng ta sẽ thấy.
Câu lệnh thứ hai gần với truy vấn chụp nhanh ban đầu hơn, ngoại trừ bây giờ chúng ta có một WHERE mới lọc mệnh đề trên CityID cột. Từ đó, chúng ta có thể thấy rằng đó là tìm nạp một hàng. Chúng tôi có thể sử dụng các khóa mà chúng tôi có được từ truy vấn đầu tiên và thu thập phần còn lại của các cột trong truy vấn này. Bất cứ khi nào câu lệnh đã chuẩn bị đó được thực thi, bạn sẽ thấy SQLExecute: (GOTO BOOKMARK) .
Nhưng điều đó sẽ không hiệu quả nếu chúng ta phải làm điều này cho tất cả các hàng… Và đó là nơi xuất hiện truy vấn tiếp theo. Câu lệnh thứ 3 tương tự như câu lệnh thứ 2 nhưng có 10 vị từ. Truy vấn đã chuẩn bị này được thực thi với mỗi SQLExecute: (MULTI_ROW FETCH) . Vì vậy, điều này có nghĩa là khi chúng tôi tải một biểu mẫu hoặc một biểu dữ liệu hoặc thậm chí mở một tập bản ghi bằng mã VBA, Access sẽ sử dụng phiên bản một hàng hoặc phiên bản nhiều hàng và điền vào các tham số bằng các khóa mà nó nhận được từ phiên bản đầu tiên. truy vấn.
Tìm nạp nền và đồng bộ hóa lại
Nhân tiện, bạn đã bao giờ nhận thấy khi mở biểu mẫu hoặc biểu dữ liệu, bạn không thấy “X of Y” trong thanh điều hướng không?
Đó là vì Access không thể biết có bao nhiêu cho đến khi hoàn tất việc thu thập kết quả từ truy vấn đầu tiên. Đó là lý do tại sao bạn có thể thường thấy rằng rất nhanh khi mở một truy vấn trả về một lượng lớn dữ liệu. Bạn chỉ xem trước một cửa sổ nhỏ của toàn bộ tập bản ghi trong khi Access đang tìm nạp các hàng trong nền. Nếu bạn nhấp vào nút “Tới Cuối cùng”, khi đó bạn có thể thấy rằng nó đóng băng Quyền truy cập. Bạn sẽ phải đợi cho đến khi nó hoàn tất tìm nạp tất cả các khóa trong truy vấn đầu tiên trước khi chúng tôi có thể nhìn thấy “X of Y” trong thanh điều hướng.
Vì vậy, bạn có thể đánh giá cao cách Access có thể mang lại ảo giác nhanh chóng mở ngay cả một tập bản ghi lớn khi chúng ta sử dụng một bộ bản ghi loại dynaset và đó thường là một trải nghiệm tốt cho người dùng.
Cuối cùng, chúng ta cần lưu ý rằng chúng ta có 3 loại thực thi khác nhau, SQLExecDirect , SQLPrepare và SQLExecute . Bạn có thể thấy rằng với cái trước, chúng tôi không có bất kỳ thông số nào. Truy vấn đơn giản là nguyên trạng. Tuy nhiên, nếu một truy vấn cần được tham số hóa, thì nó phải được chuẩn bị trước qua SQLPrepare và sau đó được thực thi với SQLExecute với các giá trị cho các tham số được cung cấp. Chúng tôi không thể thấy những giá trị nào thực sự được chuyển vào SQLExecute mặc dù chúng ta có thể suy ra từ những gì chúng ta thấy trong Access. Bạn chỉ có thể biết liệu nó có được tìm nạp một hàng hay không (sử dụng SQLExecute: (GOTO BOOKMARK) hoặc nhiều hàng (sử dụng SQLExecute: (MULTI-ROW FETCH) ). Access sẽ sử dụng phiên bản nhiều hàng để thực hiện tìm nạp nền và lấp đầy tập bản ghi tăng dần nhưng sử dụng phiên bản một hàng để chỉ lấp đầy một hàng. Đó có thể là trường hợp trên một dạng xem biểu mẫu đơn lẻ trái ngược với dạng liên tục hoặc dạng xem biểu dữ liệu hoặc sử dụng nó để đồng bộ hóa lại sau khi cập nhật.
Điều hướng xung quanh
Với một tập bản ghi đủ lớn, Access có thể không bao giờ hoàn tất việc tìm nạp tất cả các bản ghi. Như đã lưu ý trước đây, người dùng được cung cấp dữ liệu càng sớm càng tốt. Thông thường, khi người dùng điều hướng chuyển tiếp qua tập bản ghi, Access sẽ tiếp tục tìm nạp ngày càng nhiều bản ghi để giữ bộ đệm trước người dùng.
Nhưng giả sử rằng người dùng nhảy đến hàng thứ 100 bằng cách đi tới điều khiển điều hướng và nhập 100 ở đó?
Trong trường hợp đó, Access sẽ gửi các truy vấn sau…
SQLExecute: (MULTI-ROW FETCH) SQLExecute: (GOTO BOOKMARK) SQLExecute: (MULTI-ROW FETCH) SQLExecute: (MULTI-ROW FETCH)Lưu ý cách Access sử dụng các câu lệnh đã được chuẩn bị sẵn mà nó đã tạo tại thời điểm mở tập bản ghi. Bởi vì nó đã có các khóa từ truy vấn đầu tiên, nó có thể biết đâu là hàng "thứ 100". Để sử dụng một ví dụ cụ thể hơn. Giả sử rằng chúng ta có
CityID bắt đầu từ 1, 3, 4, 5… 99, 100, 101, 102 mà không có bản ghi nào cho CityID = 2 . Trong truy vấn đầu tiên, CityID 101 sẽ ở hàng thứ 100. Do đó, khi người dùng nhảy đến 100, Access sẽ tìm kiếm hàng thứ 100 trong truy vấn đầu tiên, xem đó là CityID 101, sau đó lấy giá trị đó và nạp giá trị đó vào SQLExecute: (GOTO BOOKMARK) để điều hướng ngay đến bản ghi đó. Sau đó, nó sẽ xem xét 10 bản ghi tiếp theo và sử dụng CityID tiếp theo đó để lấp đầy bộ đệm với nhiều SQLExecute: (MULTI-ROW FETCH) . Bạn có thể nhận thấy rằng có nhiều hàng được tìm nạp trước khi tìm nạp một hàng. Access thực sự đang tìm nạp hàng thứ 101-110 trong nhiều hàng tìm nạp và tìm nạp bản ghi thứ 100 trong lần tìm nạp hàng đơn tiếp theo. Khi Access đã lấy dữ liệu cho các hàng ở vị trí thứ 100. Nó sẽ đưa người dùng đến đó, sau đó bắt đầu lấp đầy bộ đệm xung quanh hàng thứ 100 đó. Điều đó cho phép người dùng xem hàng thứ 100 mà không cần phải đợi tải tất cả các bản ghi thứ 11 đến 99. Người dùng cũng có trải nghiệm duyệt nhanh rõ ràng khi người dùng nhấp vào trước đó hoặc tiếp theo từ vị trí mới vì Access đã tải nó ở chế độ nền trước khi người dùng yêu cầu. Điều đó giúp tạo ra ảo giác về tốc độ nhanh ngay cả khi qua mạng chậm.
Nhưng ngay cả khi người dùng để biểu mẫu mở và không hoạt động, Access sẽ tiếp tục thực hiện cả tìm nạp nền và làm mới bộ đệm để tránh hiển thị dữ liệu cũ của người dùng. Điều đó được điều chỉnh bởi cài đặt ODBC trong hộp thoại Tùy chọn, trong phần Nâng cao trong tab Cài đặt máy khách:
Khoảng thời gian làm mới ODBC mặc định là 1500 giây nhưng có thể thay đổi. Nó cũng có thể được thay đổi thông qua VBA.
Kết luận:Chunky hoặc Chatty
Bây giờ bạn sẽ thấy rằng lý do chính tại sao tập bản ghi kiểu dynaset có thể cập nhật được nhưng tập hợp bản ghi kiểu ảnh chụp nhanh thì không là vì Access có thể thay thế một hàng trong tập bản ghi bằng phiên bản mới nhất của cùng một máy chủ vì nó biết cách chọn một hàng đơn. Vì lý do đó, Access cần quản lý 2 truy vấn ODBC; một để tìm nạp các khóa và một để tìm nạp nội dung thực tế của các hàng cho một khóa nhất định. Thông tin đó không có trong tập bản ghi loại ảnh chụp nhanh. Chúng tôi vừa có một khối dữ liệu lớn.
Chúng tôi đã xem xét 2 loại bộ ghi chính mặc dù có nhiều loại hơn. Tuy nhiên, những loại khác chỉ là biến thể của 2 loại chúng tôi đã đề cập. Nhưng hiện tại, cần nhớ rằng để sử dụng snapshot là phải khéo léo trong giao tiếp mạng của chúng ta. Mặt khác, sử dụng dynaset có nghĩa là chúng ta sẽ tán gẫu. Cả hai đều có những thăng trầm.
Ví dụ:tập hợp bản ghi ảnh chụp nhanh không cần giao tiếp với máy chủ sau khi nó đã truy xuất dữ liệu. Miễn là tập bản ghi vẫn mở, Access có thể tự do điều hướng xung quanh bộ nhớ cache cục bộ của nó. Quyền truy cập cũng không cần giữ bất kỳ ổ khóa nào và do đó chặn những người dùng khác. Tuy nhiên, tập bản ghi ảnh chụp nhanh cần mở chậm hơn vì nó phải thu thập tất cả dữ liệu từ trước. Nó có thể không phù hợp với một bộ hồ sơ lớn, ngay cả khi bạn định đọc tất cả dữ liệu.
Giả sử rằng bạn đang tạo một báo cáo Access lớn với 100 trang, thì việc sử dụng bộ bản ghi kiểu dynaset thường rất đáng giá. Nó có thể bắt đầu hiển thị bản xem trước ngay khi có đủ để hiển thị trang đầu tiên. Điều đó tốt hơn là buộc bạn phải đợi cho đến khi nó truy xuất tất cả dữ liệu trước khi nó có thể bắt đầu hiển thị bản xem trước. Mặc dù một bộ hồ sơ dynaset có thể bị khóa, nhưng nó thường là trong thời gian ngắn. Nó chỉ đủ dài để Access đồng bộ hóa lại bộ đệm cục bộ của nó.
Nhưng khi chúng tôi nghĩ về số lượng yêu cầu Access gửi qua mạng bằng tập bản ghi kiểu dynaset, chúng ta dễ dàng nhận thấy rằng nếu độ trễ mạng thấp, hiệu suất của Access sẽ bị ảnh hưởng theo. Để Access cho phép người dùng chỉnh sửa và cập nhật các nguồn dữ liệu theo cách chung chung, Access yêu cầu Access phải theo dõi các phím để chọn và sửa đổi một hàng. Chúng ta sẽ xem xét vấn đề này trong các bài viết sắp tới. Trong bài tiếp theo, chúng ta sẽ xem xét cách sắp xếp và nhóm ảnh hưởng đến tập bản ghi kiểu dynaset cũng như cách Access xác định khóa để sử dụng cho tập bản ghi kiểu dynaset.
Để được trợ giúp thêm về Microsoft Access, hãy gọi cho các chuyên gia của chúng tôi theo số 773-809-5456 hoặc gửi email cho chúng tôi theo địa chỉ [email protected].
