Bagaimana Access berbicara dengan sumber data ODBC? Bagian 2

PERBARUI: Menambahkan beberapa klarifikasi lagi seputar arti SQLExecute dan bagaimana Access menangani kueri yang disiapkan. Terima kasih, Bob!

Apa yang Access lakukan saat kami menelusuri dan melihat catatan di tabel tertaut ODBC?

Di bagian kedua dari seri penelusuran ODBC kami, fokus kami akan beralih ke dampak yang dimiliki tipe recordset dalam tabel tertaut ODBC. Pada artikel terakhir kita telah mempelajari cara mengaktifkan ODBC SQL trace dan sekarang kita dapat melihat hasilnya. Jika Anda telah memainkannya sedikit, Anda mungkin telah memperhatikan bahwa kueri Access Anda dan pernyataan SQL ODBC yang dihasilkan Access tidak terlihat sangat mirip. Kami juga akan memberikan pandangan mendalam tentang bagaimana jenis memengaruhi perilaku kueri SELECT, dan kami juga akan melihat berbagai variasi kumpulan rekaman seperti Snapshots dan Dynasets.

Jika Anda ingin mengikuti, Anda dapat menggunakan database sampel yang disediakan di sini.

Pengaruh jenis Recordset dalam kueri SELECT

Jenis kumpulan catatan memiliki pengaruh besar pada bagaimana Access akan berkomunikasi dengan sumber data ODBC. Anda mungkin telah memperhatikan bahwa dalam tampilan desain formulir atau dalam tampilan desain kueri, Anda bisa mengatur tipe kumpulan rekaman. Secara default, ini diatur ke Dynaset .

Di VBA, kami memiliki beberapa opsi lagi tetapi kami tidak akan khawatir tentang itu untuk saat ini. Mari kita mulai dengan memahami apa sebenarnya Dynaset dan Snapshot berarti pertama. Kita akan mulai dengan jenis yang jarang digunakan, Snapshot pertama.

Set rekaman jenis snapshot

Snapshot cukup sederhana. Ini pada dasarnya berarti kita mengambil snapshot dari hasil pada saat eksekusi query. Biasanya, ini juga berarti Access tidak dapat memperbarui hasilnya. Namun, mari kita lihat bagaimana Access mengkueri sumber dengan kumpulan rekaman berbasis snapshot. Kami dapat membuat kueri Access baru seperti ini:

SQL seperti yang dapat kita lihat dalam tampilan SQL kueri Access adalah:

SELECT Cities.*
FROM Cities;

SQLExecDirect:
SELECT
   "CityID"
  ,"CityName"
  ,"StateProvinceID"
  ,"Location"
  ,"LatestRecordedPopulation"
  ,"LastEditedBy"
  ,"ValidFrom"
  ,"ValidTo"
FROM "Application"."Cities"

1. Akses memenuhi syarat tabel dengan nama skema. Jelas, dalam dialek Access SQL, itu tidak bekerja dengan cara yang sama tetapi untuk dialek ODBC SQL, akan sangat membantu untuk memastikan bahwa kita memilih dari tabel yang benar. Itu diatur oleh SourceTableName properti.
2. Akses memperluas konten Cities.* ke dalam daftar enumerasi dari semua kolom yang sudah diketahui Access berdasarkan Fields kumpulan TableDef yang mendasarinya objek.
3. Akses menggunakan " untuk mengutip pengidentifikasi, yang diharapkan oleh dialek ODBC SQL. Meskipun Access SQL dan Transact-SQL menggunakan tanda kurung untuk mengutip pengenal, itu bukan sintaks legal dalam dialek SQL ODBC.

Jadi meskipun kami hanya melakukan kueri snapshot sederhana yang memilih semua kolom untuk tabel, Anda dapat melihat bahwa Access melakukan banyak transformasi ke SQL antara apa yang Anda masukkan ke dalam tampilan desain kueri Access atau tampilan SQL versus apa yang sebenarnya dipancarkan Access ke data sumber. Namun, dalam kasus ini, sebagian besar sintaksis sehingga tidak ada perbedaan nyata dalam pernyataan SQL antara kueri Access asli dan pernyataan SQL ODBC.

Jejak juga menambahkan SQLExecDirect di awal pernyataan SQL. Kami akan kembali ke sana setelah melihat beberapa contoh lainnya.

Dataset tipe Dynaset

Kami akan menggunakan kueri yang sama tetapi mengubah properti kembali ke default, Dynaset .
Jalankan lagi, dan kita akan melihat apa yang kita dapatkan dari sqlout.txt . Sekali lagi, ini diformat agar mudah dibaca:

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)

Yang pertama hanya memilih CityID kolom. Itu adalah kunci utama tabel, tetapi yang lebih penting, itu adalah indeks yang digunakan Access di sisinya. Itu akan menjadi penting ketika kita mempelajari pandangan nanti. Access menggunakan kueri ini untuk mendapatkan kunci dan menggunakannya untuk mengisi kueri lain nanti seperti yang akan kita lihat.

Pernyataan kedua lebih mendekati kueri snapshot asli, kecuali sekarang kita memiliki WHERE . yang baru pemfilteran klausa pada CityID kolom. Dari situ kita dapat melihat bahwa ini adalah pengambilan satu baris. Kami dapat menggunakan kunci yang kami dapatkan dari kueri pertama dan mengumpulkan kolom lainnya dalam kueri ini. Setiap kali pernyataan yang disiapkan itu dieksekusi, Anda akan melihat SQLExecute: (GOTO BOOKMARK) .

Tapi itu tidak efisien jika kita harus melakukan ini untuk semua baris… Dan di situlah kueri berikutnya masuk. Pernyataan ke-3 mirip dengan yang ke-2 tetapi memiliki 10 predikat. Kueri yang disiapkan ini dijalankan dengan setiap SQLExecute: (MULTI_ROW FETCH) . Jadi ini artinya ketika kita memuat formulir atau lembar data atau bahkan membuka kumpulan rekaman dalam kode VBA, Access akan menggunakan versi baris tunggal atau versi banyak baris dan mengisi parameter menggunakan kunci yang didapat dari yang pertama kueri.

Pengambilan latar belakang dan sinkronisasi ulang

Kebetulan, pernahkah Anda memperhatikan bagaimana ketika Anda membuka formulir atau lembar data, Anda tidak melihat "X dari Y" di bilah navigasi?

Itu karena Access tidak dapat mengetahui berapa banyak sampai selesai mengumpulkan hasil dari kueri pertama. Itulah mengapa Anda mungkin sering menemukan bahwa sangat cepat untuk membuka kueri yang mengembalikan data dalam jumlah besar. Anda hanya melihat pratinjau hanya jendela kecil dari seluruh kumpulan rekaman saat Access mengambil baris di latar belakang. Jika Anda mengklik tombol "Go To Last", Anda mungkin menemukan bahwa Access membeku. Anda harus menunggu sampai selesai mengambil semua kunci dalam kueri pertama sebelum kita dapat melihat “X dari Y” di bilah navigasi.

Dengan demikian, Anda dapat menghargai bagaimana Access dapat memberikan ilusi untuk membuka bahkan kumpulan rekaman besar saat kami menggunakan recordset tipe dynaset dan itu biasanya merupakan pengalaman yang baik bagi pengguna.

Terakhir, kita perlu mencatat bahwa kita mendapatkan 3 jenis eksekusi yang berbeda, SQLExecDirect , SQLPrepare dan SQLExecute . Anda dapat melihat bahwa dengan yang pertama, kami tidak memiliki parameter apa pun. Kueri hanya apa adanya. Namun, jika kueri perlu diparameterisasi, kueri harus disiapkan terlebih dahulu melalui SQLPrepare dan kemudian dieksekusi dengan SQLExecute dengan nilai untuk parameter yang disediakan. Kami tidak dapat melihat nilai apa yang sebenarnya diteruskan ke SQLExecute pernyataan meskipun kita dapat menyimpulkan dari apa yang kita lihat di Access. Anda hanya dapat mengetahui apakah itu mengambil satu baris (menggunakan SQLExecute: (GOTO BOOKMARK) atau beberapa baris (menggunakan SQLExecute: (MULTI-ROW FETCH) ). Access akan menggunakan versi beberapa baris untuk melakukan pengambilan latar belakang dan mengisi kumpulan rekaman secara bertahap tetapi menggunakan versi baris tunggal untuk mengisi hanya satu baris. Itu mungkin terjadi pada tampilan formulir tunggal sebagai lawan dari formulir berkelanjutan atau tampilan lembar data atau menggunakannya untuk menyinkronkan ulang setelah pembaruan.

Menjelajahi

Dengan kumpulan rekaman yang cukup besar, Access mungkin tidak akan pernah bisa menyelesaikan pengambilan semua rekaman. Seperti disebutkan sebelumnya, pengguna disajikan dengan data sesegera mungkin. Biasanya, saat pengguna menavigasi maju melalui kumpulan catatan, Access akan terus mengambil lebih banyak catatan untuk menjaga buffer tetap di depan pengguna.

Namun, misalkan pengguna melompat ke baris ke-100 dengan membuka kontrol navigasi dan memasukkan 100 di sana?

Dalam hal ini, Access akan mengirimkan kueri berikut…

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (GOTO BOOKMARK)

SQLExecute: (MULTI-ROW FETCH)

SQLExecute: (MULTI-ROW FETCH)

Setelah Access mendapatkan data untuk baris ke-100. Dibutuhkan pengguna di sana, lalu mulai mengisi buffer di sekitar baris ke-100 itu. Itu memungkinkan pengguna untuk melihat baris ke-100 tanpa harus menunggu untuk memuat semua catatan ke-11-99. Pengguna juga tampaknya memiliki pengalaman menjelajah yang cepat saat pengguna mengklik sebelumnya atau berikutnya dari posisi baru karena Access telah memuatnya di latar belakang sebelum pengguna memintanya. Itu membantu memberikan ilusi menjadi cepat bahkan melalui jaringan yang lambat.

Tetapi bahkan jika pengguna membiarkan formulir terbuka dan menganggur, Access akan terus melakukan pengambilan latar belakang dan menyegarkan buffer untuk menghindari menampilkan data basi pengguna. Itu diatur oleh pengaturan ODBC di dialog Opsi, di bawah bagian Lanjutan di tab Pengaturan Klien:

Default untuk interval penyegaran ODBC adalah 1500 detik tetapi dapat diubah. Itu juga dapat diubah melalui VBA.

Kesimpulan:Chunky atau Cerewet

Anda sekarang akan melihat bahwa alasan utama mengapa kumpulan catatan tipe dynaset dapat diperbarui tetapi kumpulan catatan tipe snapshot tidak adalah karena Access dapat mengganti baris di kumpulan catatan dengan versi terbaru yang sama dari server karena tahu cara memilih baris tunggal. Oleh karena itu, Access perlu mengelola 2 kueri ODBC; satu untuk mengambil kunci dan yang lainnya untuk mengambil konten aktual dari baris untuk kunci yang diberikan. Informasi itu tidak ada dengan recordset tipe snapshot. Kami baru saja mendapatkan sekumpulan besar data.

Kami melihat 2 jenis utama dari kumpulan rekaman meskipun ada lebih banyak lagi. Namun, yang lain hanyalah varian dari 2 tipe yang kami bahas. Namun untuk saat ini, cukup diingat bahwa menggunakan snapshot berarti menjadi chunky dalam komunikasi jaringan kita. Di sisi lain, menggunakan dynaset berarti kita akan cerewet. Keduanya memiliki pasang surut.

Misalnya, kumpulan rekaman snapshot tidak memerlukan komunikasi lebih lanjut dengan server setelah mengambil data. Selama recordset tetap terbuka, Access dapat dengan bebas menavigasi di sekitar cache lokalnya. Akses juga tidak perlu menyimpan kunci apa pun dan dengan demikian memblokir pengguna lain. Namun, kumpulan rekaman snapshot perlu dibuka lebih lambat karena harus mengumpulkan semua data di muka. Ini mungkin tidak cocok untuk kumpulan data besar, bahkan jika Anda bermaksud membaca semua data.

Misalkan Anda membuat laporan Access besar yang berisi 100 halaman, biasanya sebaiknya menggunakan recordset tipe dynaset. Itu dapat mulai merender pratinjau segera setelah cukup untuk merender halaman pertama. Itu lebih baik daripada memaksa Anda menunggu hingga semua data diambil sebelum dapat mulai merender pratinjau. Meskipun recordset dynaset mungkin terkunci, biasanya untuk waktu yang singkat. Akses hanya cukup lama untuk menyinkronkan ulang cache lokalnya.

Tetapi ketika kita memikirkan berapa banyak lagi permintaan yang Access kirimkan melalui jaringan dengan recordset tipe dynaset, mudah untuk melihat bahwa jika latensi jaringan buruk, kinerja Access akan menurun karenanya. Agar Access mengizinkan pengguna untuk mengedit dan memperbarui sumber data secara umum, Access perlu melacak kunci untuk memilih dan mengubah satu baris. Kita akan melihat ini di artikel-artikel yang akan datang. Dalam artikel berikutnya, kita akan melihat bagaimana pengurutan dan pengelompokan memengaruhi kumpulan data tipe-dinaset serta bagaimana Access menentukan kunci yang akan digunakan untuk kumpulan data tipe-dinaset.

Untuk bantuan lebih lanjut dengan Microsoft Access, hubungi pakar kami di 773-809-5456 atau email kami di [email protected].