Ikut nimbrung tanya ah ... Bang Aksan...
Kalo menggunakan link tabel jika kita melakukan tambah,edit,hapus data itukan langsung bisa berpengaruh pada tabel-tabel yang ada di back end database, sedangkan dengan menggunakan store procedure kita harus melakukan insert,update, dan delete dengan menggunakan script juga untuk mengubah data2 di tabel BE nya. Menurut bang aksan untuk hal ini lebih efektif mana untuk penambahan,edit data tersebut baik dalam hal penulisan script maupun kecepatan proses datanya.
Terima Kasih
Salam,![]()
Nyong
Salam,
Nyong
Dari: aksankurdin <aksan.kurdin@gmail.com>
Kepada: belajar-access@yahoogroups.com
Dikirim: Selasa, 28 Juni 2011 4:34
Judul: [belajar-access] Re: Prinsip kerja Link Table
maaf, saya ulangi lagi, ya bang hendra:
> Ganti backend dengan client server engine, lalu tarik data tidak lewat link
> tabel, tetapi query ke store procedure. kalau model begini, maka jika isi
> store procedurenya adalah:
> select * from customer where city = 'jakarta'
>
> maka data yang masuk ke front end access juga hanya customer jakarta saja,
> filter sudah dilaksanakan di server.
sekarang bagaimana kalau gantian, daripada kita bicara teori, nah ... coba bang hendra riset dengan memanggil link table antara back end access mdb/accdb dan back end mysql/sqlserver/postgress dll. usahakan datanya yang gede, bisa pantau dari penggunaan memori di task manager windows atau dengan process explorer punya sysinternal. nanti akan ketahuan hasil omongan panjang lebar kita di sini, betulkah teori dan hasil diskusi tersebut ?
:)
aksan kurdin
--- In belajar-access@yahoogroups.com, Hendra Agestha Hamid <the_agestha@...> wrote:
>
> Matur nuwun Mas Aksan....
>
> Kalo kalo saya gak salah tangkap dari penjelasan Mas, Link Table sebenarnya
> memang adalah fungsi koneksi saja ya mas, seperti
>
> kalo kita tulis di VBA. Cuma Link Table dibuat dengan koneksi DAO sbg default
> access..?
>
> Kemudian tentang cara kerja eksekusi Query atau perintah SQL seperti yang mas
> jelaskan bahwa seluruh tabel akan di donload
> dulu baru di filter di FE, Jika kita pakai BE MySQL apakah juga seperti itu cara
> kerjanya..? pointnya adalah apapun BE nya maka
> cara kerja FE Access adalah tetap seperti yang mas jelaskan itu.
>
> Regards
> Hendra
>
>
>
>
>
> ________________________________
> From: Aksan Kurdin <aksan.kurdin@...>
> To: belajar-access@yahoogroups.com
> Sent: Mon, June 27, 2011 4:25:14 PM
> Subject: Re: [belajar-access] Prinsip kerja Link Table
>
>
> pola umum pembahasannya adalah mengakses database melalui perangkat
> developer tools seperti .net (vb/c#) atau dari delphi, bukan dari access to
> access :)
>
> quotes:
> Jadi, apa benar ada link table ? Tidak. Yang ada adalah Access memindahkan
> seluruh data dari asal ke dalam memori, dengan rentang refresh data yaitu
> setiap ada eksekusi query yang merujuk ke "link table" ini. Bisa
> dibayangkan ? Coba tambahkan bayangannya sebagai berikut :
> Ketika ada perintah dari form untuk ambil semua data dari field nama di
> link tabel ( SELECT nama FROM myLinkTable ) dan anggap saja diberi nama
> q1, maka Access akan segera membaca tabel di database awal, menyusun
> temporary table, dan mengeksekusi query q1. Bagaimana jika q1 dilakukan
> setiap detik ?
>
> aksan:
> loh beneran ada ....., tuh iconnya tampak :)
> query dari link table di access memang kerjanya begitu, bahkan jika
> membuka query melalui code vba - obyek command/recordset/connection.
> semua tabel selalu di download ke client dulu, baru di client filter akan
> dilakukan.
> select * from customer where city = 'jakarta'
> perintah ini, baik dari link table customer, atau dari script vba, akan
> selalu mengerjakan select * from customer dulu, baru where citiy =
> 'jakarta' di lakukan di client.
> itu kekurangan front end access untuk link tabel / script vba yang
> memanggil query / tabel.
> mengenai obyek link table, itu beneran ada, ia adalah referensi yang
> menunjuk ke tabel yang sebenarnya di database yang sebenarnya, jadi
> menghemat penulisan connection string saja.
> pertanyaan selanjutnya, bagaimana jika q1 dilakukan setiap detik ?
> jawabannya sama seperti untuk quotes berikutnya:
>
>
> quotes:
> Oke... sampai sini, dapat disimpulkan bahwa satu link table pasti berupa
> satu koneksi dan satu recordset.
> Jika punya 17 link table bagaimana ? Jika setiap table berisi data 500 MB
> bagaimana ? Jangan lupa, memori yang digunakan adalah RAM + pagefile OS.
> Jadi, bagaimana jika kapasitas harddisk tidak mencukupi ? hehehehe....
> hang kali ya... atau ada pesan error data yang diminta terlalu banyak,
> jadi link table tidak bisa dilakukan (hanya mungkin loh)
> Padahal q1 yang lengkap dengan klausa WHERE hanya kan menghasilkan
> maksimal 100 record dari 3 kolom saja (misalnya),
>
> kenapa harus repot menyediakan semua data di memori ?
>
> aksan:
> jika sampai 17 table tersebut berisi 500 MB data, jawabannya access mdb
> sudah tidak tepat jadi back-end-nya.
>
> Ganti backend dengan client server engine, lalu tarik data tidak lewat link
> tabel, tetapi query ke store procedure. kalau model begini, maka jika isi
> store procedurenya adalah:
> select * from customer where city = 'jakarta'
>
> maka data yang masuk ke front end access juga hanya customer jakarta saja,
> filter sudah dilaksanakan di server.
>
>
>
> aksan kurdin
>
>
>
>
> On 6/27/2011 12:13 PM, hari yanto wrote:
>
> >Uraian dan pemahaman yang menarik. Dasar
> >logika umum pembuatan program. Memisahkan
> >antara database, bahasa komunikasi dengan
> >database, dan cara menayangkan hasil.
> >
> >
> >--- On Sun, 26/6/11, Hendra Agestha Hamid
> ><the_agestha@...> wrote:
> >
> >
> >>From: Hendra Agestha Hamid <the_agestha@...>
> >>Subject: [belajar-access] Prinsip kerja Link
> >>Table
> >>To: belajar-access@yahoogroups.com
> >>Date: Sunday, 26 June, 2011, 8:47 AM
> >>
> >>
> >>
> >>Dear Warga Milis,...
> >>Saya ada "ngobrol" dengan seseorang,
> >>sampai kemudian pembahasan tentang
> >>Link Table, mohon terutama tanggapan
> >>rekan2 semua apa benar
> >>prinsip kerja Link Table seperti
> >>dibawah ini (saya Copas dari "obrolan"
> >>saya) :
> >>
> >>
> >>Mari diurai satu per satu.
> >>
> >>A. Database dan table/view
> >>Database adalah kumpulan data yang
> >>satu tema. Database berisi tabel dan
> >>view yang masing-masingnya adalah
> >>satu pokok bahasan.
> >>Database memiliki struktur, antara
> >>lain struktur :
> >>1. cara berhubungan dengan dunia
> >>luar yang sering disebut koneksi,
> >>yang kalimat percakapannya
> >>disebut Connection String.
> >>Komunikasi dengan dunia luar
> >>dilakukan oleh database melalui agen
> >>database. Agen database sering
> >>disebut Data Provider. Pihak luar
> >>yang berhubungan dengan database
> >>adalah Data Object seperti DAO dan
> >>ADO. Jadi, siapa saja dan darimana
> >>saja pihak luar yang akan
> >>berhubungan dengan database, pasti
> >>butuh sosok Data Object dan Data
> >>Provider.
> >>2. cara menginterogasi database yang
> >>sering disebut Command Text, yang
> >>bahasanya hanya satu, yaitu SQL.
> >>Versi SQL dan varian SQL yang
> >>digunakan, tergantung database
> >>tersebut. Contoh, MS SQL Server
> >>menggunakan versi SQL ANSI 90 dengan
> >>varian T-SQL. Oracle dengan ANSI 90
> >>varian PL/SQL, dsb.
> >>3. katalog object database yang
> >>berisi daftar tabel beserta struktur
> >>tabel, relasi antar tabel maupun
> >>antar view, dan semua object
> >>database seperti security, view (di
> >>akses sering disebut Query Object),
> >>object programmability (akses tidak
> >>punya), trigger dan validasi (akses
> >>hanya punya validasi berdasar
> >>datatype saja).
> >>
> >>B. Koneksi.
> >>Koneksi database selalu membutuhkan Connection
> >>String.
> >>
> >>C. Interogasi database
> >>Selalu berupa query yang dieksekusi
> >>oleh Data Object melalu object
> >>Connection-nya.
> >>
> >>D. Wujud database.
> >>Bisa terikat kepada sebuah server,
> >>ataupun sebagai file mandiri. Contoh
> >>yang terikat kepada server data
> >>adalah database di MySQL, Oracle,
> >>DB2, MS SQL Server. Contoh sebagai
> >>file mandiri adalah database SQLite,
> >>Access (bukan bagian VBA nya, tapi
> >>murni tabel dan object query nya),
> >>Excel, Text File terstruktur, dsb.
> >>
> >>Nah.. dari hal-hal diatas,
> >>Dimanakah letak link table ?
> >>Link table adalah sebutan untuk
> >>proses koneksi ke database lain. Di
> >>belakang layar link table, ada
> >>proses koneksi oleh data object
> >>(DAO) menggunakan Data Provider yang
> >>bisa berupa ODBC maupun OLE DB,
> >>melalui kalimat percakapan yang
> >>disebut Connection String, disertai
> >>sebuah kalimat interogasi database
> >>yang disebut Command Text yang
> >>berupa Query.
> >>
> >>Jika hubungan antar database pada
> >>link table itu dituliskan sebagai
> >>sebuah script, maka yang dibutuhkan
> >>adalah script dengan maksimal 5
> >>baris, mulai dari koneksi sampai
> >>memegang hasil query. Koneksi
> >>dikelola oleh data object berupa
> >>object connection. Hasil query
> >>dikelola oleh data object berupa
> >>object recordset. Jadi link table
> >>selalu berisi 2 object pokok, yaitu
> >>object connection dan object
> >>recordset. Kedua object ini adalah
> >>milik data object, yang di access by
> >>default adalah DAO. Proses akan
> >>melalui pembacaan katalog database
> >>yang dikoneksi, untuk mendapatkan
> >>struktur tabel yang akan di-"link",
> >>disertai pembuatan temporary table
> >>berdasar katalog itu. Query yang
> >>digunakan oleh link table pada
> >>bagian menghubungkan database ini,
> >>adalah SELECT * FROM
> >>nama_tabel_pilihan_user
> >>
> >>Usai membentuk hubungan, kemudian
> >>dilakukan poenyusunan virtual
> >>catalog, yang lebih tepat disebut
> >>pemanfaatan temporary table. Hasil
> >>query oleh bagian hubungan akan di
> >>query insert into ke temporary
> >>table. Jadi query lengkap yang
> >>digunakan oleh link table bisa
> >>berupa :
> >>
> >>SELECT * FROM
> >>nama_tabel_pilihan_user INTO access_temporary_table_bernama_anu
> >>
> >>Seluruh object query atau eksekusi
> >>query yang merujuk ke "link table"
> >>adalah merujuk ke temporary table
> >>ini.
> >>
> >>Jadi, apa benar ada link table ?
> >>Tidak. Yang ada adalah Access
> >>memindahkan seluruh data dari asal
> >>ke dalam memori, dengan rentang
> >>refresh data yaitu setiap ada
> >>eksekusi query yang merujuk ke "link
> >>table" ini. Bisa dibayangkan ? Coba
> >>tambahkan bayangannya sebagai
> >>berikut :
> >>Ketika ada perintah dari form untuk
> >>ambil semua data dari field nama di
> >>link tabel ( SELECT nama FROM
> >>myLinkTable ) dan anggap saja diberi
> >>nama q1, maka Access akan segera
> >>membaca tabel di database awal,
> >>menyusun temporary table, dan
> >>mengeksekusi query q1. Bagaimana
> >>jika q1 dilakukan setiap detik ?
> >>
> >>Tidak ada link table di-dunia
> >>database kecuali jika disebut
> >>otomasi membaca data dari luar
> >>database. Semua bentuk seperti ini,
> >>pasti akan lambat, meski dilakukan
> >>berupa linked server di MS SQL
> >>Server. Link table di Access berbeda
> >>dengan Linked Server di MS SQL
> >>Server. Linked Server tidak pernah
> >>membuat temporary table dan
> >>memindahkan semua data yang
> >>dikoneksi ke dalam server. Itu
> >>sebabnya linked server relatif lebih
> >>cepat, karena yang dieksekusi selalu
> >>query dari user dan hasilnya
> >>langsung ditampilkan dari recordset
> >>yang terbentuk oleh data object
> >>milik si server. Data object milik
> >>server lebih robust dan sangat cepat
> >>bekerja dibanding data object
> >>seperti DAO maupun ADO, sayangnya,
> >>hanya bisa digunakan oleh server itu
> >>sendiri karena terkait dengan system
> >>server secara keseluruhan.
> >>
> >>Oke... sampai sini, dapat
> >>disimpulkan bahwa satu link table
> >>pasti berupa satu koneksi dan satu
> >>recordset.
> >>Jika punya 17 link table bagaimana ?
> >>Jika setiap table berisi data 500 MB
> >>bagaimana ? Jangan lupa, memori yang
> >>digunakan adalah RAM + pagefile OS.
> >>Jadi, bagaimana jika kapasitas
> >>harddisk tidak mencukupi ?
> >>hehehehe.... hang kali ya... atau
> >>ada pesan error data yang diminta
> >>terlalu banyak, jadi link table
> >>tidak bisa dilakukan (hanya mungkin
> >>loh)
> >>Padahal q1 yang lengkap dengan
> >>klausa WHERE hanya kan menghasilkan
> >>maksimal 100 record dari 3 kolom
> >>saja (misalnya),
> >>
> >>kenapa harus repot menyediakan semua
> >>data di memori ?
> >>
> >>
>
> Ganti backend dengan client server engine, lalu tarik data tidak lewat link
> tabel, tetapi query ke store procedure. kalau model begini, maka jika isi
> store procedurenya adalah:
> select * from customer where city = 'jakarta'
>
> maka data yang masuk ke front end access juga hanya customer jakarta saja,
> filter sudah dilaksanakan di server.
sekarang bagaimana kalau gantian, daripada kita bicara teori, nah ... coba bang hendra riset dengan memanggil link table antara back end access mdb/accdb dan back end mysql/sqlserver/postgress dll. usahakan datanya yang gede, bisa pantau dari penggunaan memori di task manager windows atau dengan process explorer punya sysinternal. nanti akan ketahuan hasil omongan panjang lebar kita di sini, betulkah teori dan hasil diskusi tersebut ?
:)
aksan kurdin
--- In belajar-access@yahoogroups.com, Hendra Agestha Hamid <the_agestha@...> wrote:
>
> Matur nuwun Mas Aksan....
>
> Kalo kalo saya gak salah tangkap dari penjelasan Mas, Link Table sebenarnya
> memang adalah fungsi koneksi saja ya mas, seperti
>
> kalo kita tulis di VBA. Cuma Link Table dibuat dengan koneksi DAO sbg default
> access..?
>
> Kemudian tentang cara kerja eksekusi Query atau perintah SQL seperti yang mas
> jelaskan bahwa seluruh tabel akan di donload
> dulu baru di filter di FE, Jika kita pakai BE MySQL apakah juga seperti itu cara
> kerjanya..? pointnya adalah apapun BE nya maka
> cara kerja FE Access adalah tetap seperti yang mas jelaskan itu.
>
> Regards
> Hendra
>
>
>
>
>
> ________________________________
> From: Aksan Kurdin <aksan.kurdin@...>
> To: belajar-access@yahoogroups.com
> Sent: Mon, June 27, 2011 4:25:14 PM
> Subject: Re: [belajar-access] Prinsip kerja Link Table
>
>
> pola umum pembahasannya adalah mengakses database melalui perangkat
> developer tools seperti .net (vb/c#) atau dari delphi, bukan dari access to
> access :)
>
> quotes:
> Jadi, apa benar ada link table ? Tidak. Yang ada adalah Access memindahkan
> seluruh data dari asal ke dalam memori, dengan rentang refresh data yaitu
> setiap ada eksekusi query yang merujuk ke "link table" ini. Bisa
> dibayangkan ? Coba tambahkan bayangannya sebagai berikut :
> Ketika ada perintah dari form untuk ambil semua data dari field nama di
> link tabel ( SELECT nama FROM myLinkTable ) dan anggap saja diberi nama
> q1, maka Access akan segera membaca tabel di database awal, menyusun
> temporary table, dan mengeksekusi query q1. Bagaimana jika q1 dilakukan
> setiap detik ?
>
> aksan:
> loh beneran ada ....., tuh iconnya tampak :)
> query dari link table di access memang kerjanya begitu, bahkan jika
> membuka query melalui code vba - obyek command/recordset/connection.
> semua tabel selalu di download ke client dulu, baru di client filter akan
> dilakukan.
> select * from customer where city = 'jakarta'
> perintah ini, baik dari link table customer, atau dari script vba, akan
> selalu mengerjakan select * from customer dulu, baru where citiy =
> 'jakarta' di lakukan di client.
> itu kekurangan front end access untuk link tabel / script vba yang
> memanggil query / tabel.
> mengenai obyek link table, itu beneran ada, ia adalah referensi yang
> menunjuk ke tabel yang sebenarnya di database yang sebenarnya, jadi
> menghemat penulisan connection string saja.
> pertanyaan selanjutnya, bagaimana jika q1 dilakukan setiap detik ?
> jawabannya sama seperti untuk quotes berikutnya:
>
>
> quotes:
> Oke... sampai sini, dapat disimpulkan bahwa satu link table pasti berupa
> satu koneksi dan satu recordset.
> Jika punya 17 link table bagaimana ? Jika setiap table berisi data 500 MB
> bagaimana ? Jangan lupa, memori yang digunakan adalah RAM + pagefile OS.
> Jadi, bagaimana jika kapasitas harddisk tidak mencukupi ? hehehehe....
> hang kali ya... atau ada pesan error data yang diminta terlalu banyak,
> jadi link table tidak bisa dilakukan (hanya mungkin loh)
> Padahal q1 yang lengkap dengan klausa WHERE hanya kan menghasilkan
> maksimal 100 record dari 3 kolom saja (misalnya),
>
> kenapa harus repot menyediakan semua data di memori ?
>
> aksan:
> jika sampai 17 table tersebut berisi 500 MB data, jawabannya access mdb
> sudah tidak tepat jadi back-end-nya.
>
> Ganti backend dengan client server engine, lalu tarik data tidak lewat link
> tabel, tetapi query ke store procedure. kalau model begini, maka jika isi
> store procedurenya adalah:
> select * from customer where city = 'jakarta'
>
> maka data yang masuk ke front end access juga hanya customer jakarta saja,
> filter sudah dilaksanakan di server.
>
>
>
> aksan kurdin
>
>
>
>
> On 6/27/2011 12:13 PM, hari yanto wrote:
>
> >Uraian dan pemahaman yang menarik. Dasar
> >logika umum pembuatan program. Memisahkan
> >antara database, bahasa komunikasi dengan
> >database, dan cara menayangkan hasil.
> >
> >
> >--- On Sun, 26/6/11, Hendra Agestha Hamid
> ><the_agestha@...> wrote:
> >
> >
> >>From: Hendra Agestha Hamid <the_agestha@...>
> >>Subject: [belajar-access] Prinsip kerja Link
> >>Table
> >>To: belajar-access@yahoogroups.com
> >>Date: Sunday, 26 June, 2011, 8:47 AM
> >>
> >>
> >>
> >>Dear Warga Milis,...
> >>Saya ada "ngobrol" dengan seseorang,
> >>sampai kemudian pembahasan tentang
> >>Link Table, mohon terutama tanggapan
> >>rekan2 semua apa benar
> >>prinsip kerja Link Table seperti
> >>dibawah ini (saya Copas dari "obrolan"
> >>saya) :
> >>
> >>
> >>Mari diurai satu per satu.
> >>
> >>A. Database dan table/view
> >>Database adalah kumpulan data yang
> >>satu tema. Database berisi tabel dan
> >>view yang masing-masingnya adalah
> >>satu pokok bahasan.
> >>Database memiliki struktur, antara
> >>lain struktur :
> >>1. cara berhubungan dengan dunia
> >>luar yang sering disebut koneksi,
> >>yang kalimat percakapannya
> >>disebut Connection String.
> >>Komunikasi dengan dunia luar
> >>dilakukan oleh database melalui agen
> >>database. Agen database sering
> >>disebut Data Provider. Pihak luar
> >>yang berhubungan dengan database
> >>adalah Data Object seperti DAO dan
> >>ADO. Jadi, siapa saja dan darimana
> >>saja pihak luar yang akan
> >>berhubungan dengan database, pasti
> >>butuh sosok Data Object dan Data
> >>Provider.
> >>2. cara menginterogasi database yang
> >>sering disebut Command Text, yang
> >>bahasanya hanya satu, yaitu SQL.
> >>Versi SQL dan varian SQL yang
> >>digunakan, tergantung database
> >>tersebut. Contoh, MS SQL Server
> >>menggunakan versi SQL ANSI 90 dengan
> >>varian T-SQL. Oracle dengan ANSI 90
> >>varian PL/SQL, dsb.
> >>3. katalog object database yang
> >>berisi daftar tabel beserta struktur
> >>tabel, relasi antar tabel maupun
> >>antar view, dan semua object
> >>database seperti security, view (di
> >>akses sering disebut Query Object),
> >>object programmability (akses tidak
> >>punya), trigger dan validasi (akses
> >>hanya punya validasi berdasar
> >>datatype saja).
> >>
> >>B. Koneksi.
> >>Koneksi database selalu membutuhkan Connection
> >>String.
> >>
> >>C. Interogasi database
> >>Selalu berupa query yang dieksekusi
> >>oleh Data Object melalu object
> >>Connection-nya.
> >>
> >>D. Wujud database.
> >>Bisa terikat kepada sebuah server,
> >>ataupun sebagai file mandiri. Contoh
> >>yang terikat kepada server data
> >>adalah database di MySQL, Oracle,
> >>DB2, MS SQL Server. Contoh sebagai
> >>file mandiri adalah database SQLite,
> >>Access (bukan bagian VBA nya, tapi
> >>murni tabel dan object query nya),
> >>Excel, Text File terstruktur, dsb.
> >>
> >>Nah.. dari hal-hal diatas,
> >>Dimanakah letak link table ?
> >>Link table adalah sebutan untuk
> >>proses koneksi ke database lain. Di
> >>belakang layar link table, ada
> >>proses koneksi oleh data object
> >>(DAO) menggunakan Data Provider yang
> >>bisa berupa ODBC maupun OLE DB,
> >>melalui kalimat percakapan yang
> >>disebut Connection String, disertai
> >>sebuah kalimat interogasi database
> >>yang disebut Command Text yang
> >>berupa Query.
> >>
> >>Jika hubungan antar database pada
> >>link table itu dituliskan sebagai
> >>sebuah script, maka yang dibutuhkan
> >>adalah script dengan maksimal 5
> >>baris, mulai dari koneksi sampai
> >>memegang hasil query. Koneksi
> >>dikelola oleh data object berupa
> >>object connection. Hasil query
> >>dikelola oleh data object berupa
> >>object recordset. Jadi link table
> >>selalu berisi 2 object pokok, yaitu
> >>object connection dan object
> >>recordset. Kedua object ini adalah
> >>milik data object, yang di access by
> >>default adalah DAO. Proses akan
> >>melalui pembacaan katalog database
> >>yang dikoneksi, untuk mendapatkan
> >>struktur tabel yang akan di-"link",
> >>disertai pembuatan temporary table
> >>berdasar katalog itu. Query yang
> >>digunakan oleh link table pada
> >>bagian menghubungkan database ini,
> >>adalah SELECT * FROM
> >>nama_tabel_pilihan_user
> >>
> >>Usai membentuk hubungan, kemudian
> >>dilakukan poenyusunan virtual
> >>catalog, yang lebih tepat disebut
> >>pemanfaatan temporary table. Hasil
> >>query oleh bagian hubungan akan di
> >>query insert into ke temporary
> >>table. Jadi query lengkap yang
> >>digunakan oleh link table bisa
> >>berupa :
> >>
> >>SELECT * FROM
> >>nama_tabel_pilihan_user INTO access_temporary_table_bernama_anu
> >>
> >>Seluruh object query atau eksekusi
> >>query yang merujuk ke "link table"
> >>adalah merujuk ke temporary table
> >>ini.
> >>
> >>Jadi, apa benar ada link table ?
> >>Tidak. Yang ada adalah Access
> >>memindahkan seluruh data dari asal
> >>ke dalam memori, dengan rentang
> >>refresh data yaitu setiap ada
> >>eksekusi query yang merujuk ke "link
> >>table" ini. Bisa dibayangkan ? Coba
> >>tambahkan bayangannya sebagai
> >>berikut :
> >>Ketika ada perintah dari form untuk
> >>ambil semua data dari field nama di
> >>link tabel ( SELECT nama FROM
> >>myLinkTable ) dan anggap saja diberi
> >>nama q1, maka Access akan segera
> >>membaca tabel di database awal,
> >>menyusun temporary table, dan
> >>mengeksekusi query q1. Bagaimana
> >>jika q1 dilakukan setiap detik ?
> >>
> >>Tidak ada link table di-dunia
> >>database kecuali jika disebut
> >>otomasi membaca data dari luar
> >>database. Semua bentuk seperti ini,
> >>pasti akan lambat, meski dilakukan
> >>berupa linked server di MS SQL
> >>Server. Link table di Access berbeda
> >>dengan Linked Server di MS SQL
> >>Server. Linked Server tidak pernah
> >>membuat temporary table dan
> >>memindahkan semua data yang
> >>dikoneksi ke dalam server. Itu
> >>sebabnya linked server relatif lebih
> >>cepat, karena yang dieksekusi selalu
> >>query dari user dan hasilnya
> >>langsung ditampilkan dari recordset
> >>yang terbentuk oleh data object
> >>milik si server. Data object milik
> >>server lebih robust dan sangat cepat
> >>bekerja dibanding data object
> >>seperti DAO maupun ADO, sayangnya,
> >>hanya bisa digunakan oleh server itu
> >>sendiri karena terkait dengan system
> >>server secara keseluruhan.
> >>
> >>Oke... sampai sini, dapat
> >>disimpulkan bahwa satu link table
> >>pasti berupa satu koneksi dan satu
> >>recordset.
> >>Jika punya 17 link table bagaimana ?
> >>Jika setiap table berisi data 500 MB
> >>bagaimana ? Jangan lupa, memori yang
> >>digunakan adalah RAM + pagefile OS.
> >>Jadi, bagaimana jika kapasitas
> >>harddisk tidak mencukupi ?
> >>hehehehe.... hang kali ya... atau
> >>ada pesan error data yang diminta
> >>terlalu banyak, jadi link table
> >>tidak bisa dilakukan (hanya mungkin
> >>loh)
> >>Padahal q1 yang lengkap dengan
> >>klausa WHERE hanya kan menghasilkan
> >>maksimal 100 record dari 3 kolom
> >>saja (misalnya),
> >>
> >>kenapa harus repot menyediakan semua
> >>data di memori ?
> >>
> >>
>
__._,_.___
SPAM IS PROHIBITED
.
__,_._,___
Tidak ada komentar:
Posting Komentar