Access
 sql >> Teknologi Basis Data >  >> RDS >> Access

Bagaimana Access berbicara dengan sumber data ODBC? Bagian 1

Ini adalah enam bagian seri artikel tentang pelacakan ODBC untuk membantu pengembang Access memecahkan masalah dan bekerja dengan Access saat mengembangkan aplikasi yang menggunakan sumber data ODBC, biasanya tetapi tidak secara eksklusif SQL Server. Seri ini bertujuan untuk mendemonstrasikan cara menggunakan pelacakan ODBC untuk memantau pernyataan SQL ODBC yang Access masalah di latar belakang saat bekerja dengan objek seperti kueri, formulir, atau laporan atau bahkan saat menjalankan kode VBA terhadap objek DAO. Seri ini juga akan menunjukkan bagaimana Access merumuskan pernyataan SQL ODBC. Akhirnya, seri ini akan membahas bagaimana menafsirkan penelusuran dan mengidentifikasi potensi masalah. Artikel akan dicetak setiap hari sampai seri berakhir.

PERBARUI: Menambahkan kunci registri untuk pemasangan C2R 32-bit pada Windows 64-bit. Terima kasih, Jack MacDonald!

Berapa kali Anda mendengar "Saya tidak tahu mengapa, tetapi menggoyangkan pegangannya hanya berfungsi"? Setiap kali saya mendapat tanggapan seperti itu, itu mengganggu saya karena itu sangat tidak memuaskan. Saya akan sangat prihatin jika tukang ledeng saya memberi tahu saya bahwa dia tidak tahu untuk jebakan-p dan terus menyebutnya sebagai "benda yang melengkung di bawah wastafel". Demikian juga, klien saya harus sangat khawatir jika saya berkata, “Saya tidak tahu mengapa kueri itu lambat, jadi saya mencoba beberapa hal acak dan hei, saya menemukan trik yang berhasil. Saya tidak tahu mengapa, meskipun. ” Ini mungkin salah satu larangan terbesar dalam pengembangan perangkat lunak — kami bekerja dengan sistem kompleks yang menghasilkan pergantian antara 0 dan 1 dengan sangat cepat dalam urutan tertentu dan diharapkan untuk mengetahui mengapa hal itu tidak terjadi daripada cara ini.

Saya percaya bahwa ini sepadan dengan waktu dan investasi bagi pengembang yang bekerja dengan Access dan VBA untuk benar-benar mengetahui apa yang dilakukannya, terutama dengan backend ODBC. Kami memiliki skenario migrasi di mana kami mungkin tidak memiliki akses ke alat profil sisi server karena alasan yang berbeda, tetapi itu seharusnya tidak menjadi alasan untuk mengangkat bahu dan hanya menekan tombol secara acak sampai sesuatu berfungsi. Lebih penting lagi, memiliki pemahaman yang kuat tentang apa yang terjadi di balik layar membantu Anda menjadi jauh lebih baik dalam memprediksi perbaikan kinerja apa yang perlu Anda terapkan untuk skenario tertentu. Saya menyampaikan bahwa meskipun semua yang Anda lakukan adalah membaca seri dan mempelajari cara kerja Access dengan sumber data ODBC, Anda akan jauh lebih siap hanya karena Anda tahu apa yang kemungkinan akan dilakukan Access.

Untuk skenario yang lebih rumit, penelusuran biasanya dapat melakukan keajaiban dalam mengungkapkan mengapa segala sesuatunya berjalan sangat lambat. Karena Anda dapat melacaknya di sisi Access daripada di server, itu tidak memerlukan izin yang lebih tinggi selain memiliki akses ke kunci registri untuk mengaktifkan pelacakan ODBC. Bonus tambahannya adalah ini berfungsi untuk semua sumber data ODBC, bukan hanya SQL Server jadi jika Anda memiliki klien yang menggunakan MySQL atau PostgreSQL yang tidak Anda ketahui, penelusuran ODBC masih akan membantu Anda mengidentifikasi potensi masalah yang kemudian dapat Anda atasi secara langsung. Sisi akses.

Seri akan fokus hanya dari konteks Access dan DAO. Hal-hal mungkin berbeda ketika kami menggunakan ADO di VBA tetapi itu tidak dalam cakupan untuk saat ini karena setiap kali kami menggunakan DAO, Access akan melakukan beberapa hal untuk memenuhi permintaan kami yang tidak mungkin. Contoh yang baik adalah kueri Access yang mereferensikan fungsi VBA. Anda tidak dapat menjalankan fungsi VBA di SQL Server, namun Access tidak mengeluh. Jadi apa yang sebenarnya terjadi di balik tirai? Kami dapat menemukan apa yang dilakukan Access dengan menelusuri perintah ODBC SQL yang dikeluarkannya ke sumber data ODBC.

Banyak informasi yang disajikan dalam rangkaian artikel ini dimungkinkan dengan bantuan whitepaper lama Microsoft di Jet &ODBC. Meskipun menurut saya informasinya masih sangat bermanfaat, tetapi juga cukup padat dan membutuhkan tingkat kemahiran teknis yang tinggi. Melalui rangkaian tracing diharapkan dapat membantu memaknai dan menyajikan informasi dengan lebih mudah diakses.

Mengapa kita harus melacak ODBC? Bagaimana ini akan membantu saya?

Jika Anda pernah mengalami salah satu gejala tersebut:

Atau kesalahan lainnya saat bekerja dengan tabel tertaut ODBC, maka akan bermanfaat untuk memahami mengapa Anda mendapatkan pesan tersebut dan bagaimana Anda dapat memperbaikinya. Perbaikan umum yang diterapkan beberapa pengembang Access adalah menambahkan Permintaan atau mencoba menyimpan catatan. Meskipun itu mungkin memecahkan beberapa masalah, tidak jarang kita melihat formulir Access yang kompleks ditaburi dengan bebas dengan Requery dan beberapa rangkaian peristiwa berjenjang yang kinerjanya mulai menurun. Alih-alih menaburkannya seolah-olah itu adalah debu peri ajaib, kita harus lebih berhati-hati dalam pendekatan untuk memperbaiki masalah pada aplikasi.

Alasan kuat lainnya adalah untuk dapat menganalisis mengapa formulir A tertentu membutuhkan 10 detik untuk dibuka tetapi formulir B yang serupa hanya 2 detik untuk dibuka. Alih-alih meluangkan waktu untuk mengacak-acak untuk menemukan apa yang membuat formulir A terbuka lebih cepat, Anda dapat mulai dengan menelusuri dan membandingkan perbedaannya, lalu fokus pada perbedaan tersebut untuk membantu Anda memperbaiki masalah secara lebih langsung.

Bahkan jika kami tidak selalu berakhir melacak setiap kali ada masalah kinerja, memiliki keakraban tentang apa yang harus dilakukan Access adalah nilai yang sangat besar. Jadi, meskipun Anda hanya membaca seri ini, semoga Anda lebih memahami cara bekerja dengan Access daripada melawannya.

Mengakses dialek SQL dan ODBC SQL

Sebelum kita masuk ke detailnya, kita perlu mengenali bahwa setiap kali Access bekerja dengan sumber data ODBC, Access harus terlebih dahulu menerjemahkan pernyataan SQL-nya menjadi pernyataan SQL ODBC yang valid. Ini berbeda dari dialek SQL target backend (misalnya SQL Server, Oracle, MySQL, PostgreSQL). Tata bahasa SQL ODBC dijelaskan di sini. Anda juga dapat melihat daftar semua fungsi yang didukung oleh lapisan ODBC juga. Penting untuk diingat bahwa saat kita menggunakan ODBC, sebenarnya kita tidak menerjemahkan secara langsung dari Access SQL ke dialek SQL asli sumber data. Sebaliknya, kami menerjemahkan Access SQL ke ODBC SQL yang kemudian akan diterjemahkan oleh driver ODBC untuk sumber data yang diberikan ke dalam dialek aslinya. Jika Anda dapat membayangkan seorang penutur bahasa Jepang dan penutur bahasa Prancis yang tidak berbicara bahasa satu sama lain tetapi keduanya berbicara bahasa Inggris, pada dasarnya itulah yang terjadi di atas lapisan ODBC. Konsekuensi lebih lanjut adalah bahwa hanya karena dialek ODBC mendukung fitur X, tidak berarti kedua pihak mendukungnya. Kedua belah pihak harus mendukung fitur X itu agar portabel di atas lapisan ODBC. Untungnya, sebagian besar driver ODBC di luar sana cukup luas dan melakukan pekerjaan yang baik untuk mencakup sebagian besar fitur. Jika Anda harus menghadapi situasi di mana fitur seharusnya berfungsi tetapi tidak, mungkin perlu berkonsultasi dengan dokumentasi driver ODBC untuk memverifikasi itu didukung.

Mengaktifkan pelacakan SQL ODBC

Hal pertama yang harus dilakukan agar kita bisa mengintip di balik tirai adalah mengaktifkan ODBC SQL tracing. Meskipun kita dapat menggunakan SQL Server Profiler, melihat bagaimana Access memformat ODBC SQL sangat membantu. Ini akan bekerja dengan sumber data ODBC dan bukan hanya SQL Server. Lebih penting lagi, ini memungkinkan kita melihat bagaimana Access menerjemahkan kuerinya ke ODBC dengan cara yang lebih langsung daripada SQL Server Profiler atau alat pembuatan profil sisi server lainnya. Anda tidak memerlukan izin khusus apa pun untuk menggunakan penelusuran SQL ODBC sedangkan alat profil sisi server mungkin memerlukan izin tingkat tinggi untuk digunakan. Pengaktifan ODBC SQL tracing adalah pengaturan registri sehingga kami dapat mengonfigurasinya dengan membuka kunci registri yang sesuai:

Database Jet atau versi Office sebelum 2007

Untuk Windows 32-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\4.0\Engines\ODBC

Untuk mesin Jet 32-bit atau Office pra-2007 di Windows 64-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Jet\4.0\Engines\ODBC

Catatan:Tidak ada versi 64-bit dari mesin Jet yang tidak digunakan lagi.

Office 2007 hingga 2016 (pemasangan MSI)

Untuk Office 32-bit di Windows 32-bit, atau Office 64-bit di Windows 64-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC

Untuk Office 32-bit pada Windows 64-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\Office\X.Y\Access Connectivity Engine\Engines\ODBC

(di mana X.Y sesuai dengan versi Office yang telah Anda instal)

Office 2016 atau Office 365 (Klik Untuk Menjalankan)

Untuk Office 32-bit di Windows 32-bit, atau Office 64-bit di Windows 64-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC

Untuk Office 32-bit pada Windows 64-bit:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Office\ClickToRun\REGISTRY\MACHINE\Software\Wow6432Node\Microsoft\Office\16.0\Access Connectivity Engine\Engines\ODBC

Di bawah kunci, temukan kunci TraceSQLMode dan ubah nilainya dari 0 ke 1 .

Akses perlu dimulai ulang jika sudah terbuka. Jika tidak, buka dan jalankan beberapa kueri. File bernama sqlout.txt akan dibuat di direktori saat ini. Itu biasanya di folder yang sama dengan file Access ATAU di folder dokumen. Atau, Anda dapat menjalankan fungsi VBA CurDir untuk menentukan direktori saat ini.

Saya sarankan menggunakan Notepad++ atau editor teks serupa yang memiliki kemampuan untuk mendeteksi bahwa itu telah dimodifikasi. Kemudian akan meminta untuk memuat ulang file. Itu memungkinkan Anda untuk melihat pembaruan baru saat Access mengeluarkan perintah baru ke file teks tanpa membuka kembali secara konstan. Saat Anda mengaktifkan file teks, Notepad++ akan menampilkan dialog:

Anda kemudian dapat mengklik Yes untuk melihat perintah SQL ODBC terbaru yang dikeluarkan oleh Access. Karena Access dapat mengeluarkan beberapa perintah SQL ODBC, log dapat berkembang dengan cepat. Saya merasa nyaman untuk sampai ke titik di mana saya ingin melacak sesuatu (misalnya akan membuka formulir atau menjalankan kueri), saya kemudian beralih ke sqlout.txt , muat ulang, lalu pilih semua, hapus semua teks, lalu simpan file yang sekarang kosong. Dengan begitu, saya dapat menjalankan tindakan yang ingin saya lacak, kemudian hanya melihat perintah ODBC yang relevan tanpa semua suara lain yang tidak ada hubungannya dengan tindakan yang dilacak.

Berikut video singkat untuk diperagakan:

Kesimpulan

Anda telah mempelajari cara mengaktifkan pelacakan ODBC dan melihat output yang dihasilkan oleh Access. Anda dapat melihat bahwa Anda dapat mengumpulkan output bahkan dari tindakan seperti hanya membuka tabel atau menjalankan kueri. Itu memberi Anda wawasan tentang jenis kueri SQL yang sebenarnya dikirim Access ke sumber data ODBC.

Seperti yang Anda lihat, ODBC SQL tracing menangkap semua perintah ODBC SQL yang dikeluarkan oleh Access meskipun Anda tidak secara langsung mengeluarkannya. Oleh karena itu, Anda dapat menggunakannya kapan saja di mana Anda mengalami perlambatan di mana Anda tidak memiliki penjelasan yang baik. Sebagai contoh, misalkan Anda memiliki formulir yang lambat untuk dibuka dan Anda tidak yakin itu kode VBA Anda di formulir Open atau Load peristiwa atau sumber rekaman itulah masalahnya. Strateginya adalah menyiapkan aplikasi Access sehingga Anda akan membuka formulir itu, hapus sqlout.txt file teks kemudian lanjutkan untuk membuka formulir. Anda kemudian dapat meninjau pernyataan SQL ODBC dan menentukan apakah ada yang dapat ditingkatkan.

Itu sangat berharga ketika Anda berurusan dengan formulir atau laporan kompleks yang juga berisi subformulir/sublaporan atau berisi kotak kombo atau kotak daftar yang mengeluarkan kuerinya sendiri untuk memenuhi properti sumber baris.

Pada artikel berikutnya, kita akan menganalisis output ketika kita menelusuri catatan.

Butuh bantuan dengan Microsoft Access? Hubungi tim kami di 773-809-5456 atau email kami di [email protected].


  1. Database
  2.   
  3. Mysql
  4.   
  5. Oracle
  6.   
  7. Sqlserver
  8.   
  9. PostgreSQL
  10.   
  11. Access
  12.   
  13. SQLite
  14.   
  15. MariaDB
  1. Cara Mengenkripsi Basis Data Terpisah di Access 2016

  2. [DIPERBARUI 2020-01-23] Microsoft Office 365 Build 1912 Memecah Identitas Tabel Tertaut ODBC

  3. Berapa Banyak Pengguna yang Dapat Mengakses Dukungan?

  4. Excel vs Access:Kapan Saatnya Beralih?

  5. Men-debug Prosedur Pribadi