Ikutan... Menurut saya, Query di Ms Access adalah cara gampang membuat SQL. Untuk mengetahui SQL dari query yang telah kita buat: - design view query yang akan kita lihat SQLnya
- klik View
- Pilih SQL view (contohnya: SELECT MSysObjects.Name
FROM MSysObjects WHERE (((MSysObjects.Type)=1) AND ((MSysObjects.Flags)=0)) ORDER BY MSysObjects.Name;) Ini terus kita bahasakan dalam bentuk VBA, sehingga menjadi seperti ini: Private Sub tb1() Dim rbs As Recordset dim aa as variant
Set rbs = CurrentDb.OpenRecordset("SELECT MSysObjects.Name" _ & " FROM MSysObjects WHERE MSysObjects.Type= 1 And MSysObjects.Flags = 0") If Not rbs.EOF Then do while not rbs.eof aa = aa & rbs.Fields (0) & vbCrLf rbs.MoveNext Loop End If rbs.Close Set rbs = Nothing msgbox "Nama-nama Tabel di database ini adalah :" & vbCrLf & aa
End Sub Semoga bisa membantu dan memberi semangat... Hariyanto (Surabaya)
--- On Sat, 9/7/11, Hendra Agestha Hamid <the_agestha@yahoo.com> wrote:
From: Hendra Agestha Hamid <the_agestha@yahoo.com> Subject: Re: [belajar-access] Revisi Hasil eksperimen To: "belajar-access@yahoogroups.com" <belajar-access@yahoogroups.com> Date: Saturday, 9 July, 2011, 2:56 PM
Maksud Mas Tio mengganti Query itu SQL expression ditulis di VBA terus DoCmd.RunSql gitu ya mas..?,,,kalo bukan gitu bisa minta tolong kasih contoh yg sederhana aja. Thanx
Regards Hendra
From: "tio.adjie@ptssb.co.id" <tio.adjie@ptssb.co.id> To: belajar-access@yahoogroups.com Cc: "belajar-access@yahoogroups.com" <belajar-access@yahoogroups.com> Sent: Saturday, July 9, 2011 1:06 PM Subject: Re: [belajar-access] Revisi Hasil eksperimen Menurut tips dari Mbah Google (Ma'af, agak lupa sumbernya, tapi banyak kok kalau mau di search) adalah kurang lebih : Query lebih cepat dari ADO. Saya sendiri pernah mencobanya dengan record
yang sama (kurang lebih 2000 record ke atas) dengan ADO lamanya minta ampun, tapi setelah saya coba pakai query secepat kilat. Dan ada tips yang saya lihat yang terjemahannya kurang lebih : "
Banyak database yang saya lihat (maksudnya Pakar Database yang nulis tips ini) dibangun dengan ADO , tapi sebenarnya Query lebih cepat dari itu semua". Memang
memory jadi cepat membengkak, tapi saya siasati dengan merubah query tsb. dengan SQL expression. Ya, mau gak mau , harus belajar bagaimana cara merubah query ke bahasa SQL.
regards, Tio
| Hendra Agestha Hamid <the_agestha@yahoo.com> Sent by: belajar-access@yahoogroups.com 07/08/2011 06:38 PM Please respond to belajar-access
| To: "belajar-access@yahoogroups.com" <belajar-access@yahoogroups.com> cc: Subject: Re: [belajar-access] Revisi Hasil eksperimen | Mas Tio untuk no 7 bisa lebih jelaskan kenapa kenapa untuk edit tidak ADO sedang input malah pakai ADO ? Regards Hendra
From: "tio.adjie@ptssb.co.id" <tio.adjie@ptssb.co.id> To: belajar-access@yahoogroups.com Cc: belajar-access@yahoogroups.com Sent: Friday, July 8, 2011 1:13 PM Subject: Re: [belajar-access] Revisi Hasil eksperimen Ma'af baru bisa balas sekarang, karena jaringan komputer kantor saya error akhir-akhir ini.
Saya mau share pengalaman saya dalam meningkatkan performance kecepatan database yang saya buat :
Ada beberapa hal yang saya lakukan :
1. Primary key selalu numerik karena lebih stabil dan lebil cepat 2. Redundance data (kelebihan) data selalu saya batasi yaitu dengan konnektor antar table dengan Numerik, bukan text. 3. Redundance table saya batasi juga dengan tidak membuat data yang double di tiap table. Jadi kalau ada data di table double, saya usahakan dibuat konnektor numerik. 4. Untuk filtering data, saya buat Allow Addition, Allow deletion False 5. Untuk data, sebisa mungkin adalah numerik bukan data, Untuk data dalam bentuk text biasanya saya simpan di table di FE tiap user. Adapun untuk sharing saya usahakan data type numerik. 6. Untuk table yang mencapai kapasitas besar, saya bagi beberapa table, Sehingga pengumpulan data tidak banyak yang diambil. 7. Untuk edit data, saya tidak pakai ADO, tapi pakai query. Kalau untuk tambah data, saya pakai ADO, 8. Untuk Normalisasi, sudah terjawab di no. 3.
Mudah-mudahan ini bisa bermanfaat bagi semua.
regards, Tio
| Nino Guevara Ruwano <nino@astrodigi.com> Sent by: belajar-access@yahoogroups.com 07/06/2011 01:05 PM Please respond to belajar-access | To: <belajar-access@yahoogroups.com> cc: Subject: Re: [belajar-access] Revisi Hasil eksperimen |
Dear All,
Saya perjelas kembali untuk kasus yang 28 user, bahwa seluruh user berfungsi sebagai kasir (mungkin mirip posisi kasir pada program POS gitu lah) sehingga sifat daripada manipulasi datanya adalah penambahan data (appending).
Biasanya pada database yang bikin lambat adalah pengambilan data (seperti pada query select).
Yang saya lakukan secara standar adalah: 1. Primary key sealu saya gunakan tipe data NUMERIK 2. Selalu ada Primary Key pada setiap tabel. Hal ini juga merupakan persiapan kalau2 databasenya sampai perlu export ke SQL Server, saya nggak perlu repot2 ngerubah field2 tabelnya 3. Untuk tabel yang recordnya banyak dan kapasitas nya besar saya gunakan dummy tabel sebagai perantara, dan saya hindari query yang kompleks atau yang bertingkat. 4. Pengambilan data dari BE hanya dilakukan pada tabel2 yang berkaitan dengan TRANSAKSI saja (misal: tabel_penjualan, tabel_pembelian, stok_barang, dll) Untuk tabel2 non transaksi saya letakkan di FE masing2 (misal: tabel_master_barang, tabel_data_karyawan, dll) 5. Sedapat mungkin saya hindari query yang memilih semua data (misal: select * from tabel_penjualan) 6. Perintah2 domain aggregate yang sangat menurunkan kecepatan saya hindari (DLookUp, Dmin, Dmax, dll) 7. Indexing yang tepat. Index sampe kebanyakan juga bisa bikin lambat, gunakan seperlunya pada field2 inti yang berkaitan dengan proses searching aja)
Mungkin untuk kasus2 di atas Sdr Tio Adjie sudah merasakan perbedaannya (antara sebelum dan sesudah dioptimalkan), dan dikantor Sdr Tio, MDB Access juga digunakan oleh lebih dari 5 user kok. (mana nih mas Tio . . kok diem2 aja, ikutan share doong ha ha ha . . )
Semoga share ini bisa menjawab pertanyaanya, para master di milis ini silahkan koreksi atau tambahkan bila ada salah dan kurang.
Untuk mas Yudi Hantoro, pertanyaan anda via Japri saya harap sudah terjawab dengan jawaban diatas yaa, saya jawab disini sekalian agar bisa digunakan sebagai bahan diskusi
Mohon maaf topiknya malah jadi melenceng dari Subjectnya nih, mungkin kalau mau dibahas lebih lanjut harus diganti subjectnya (misal: optimalisasi database, atau apa gitu lah ha ha ha . .:)) )
Regards,
Nino G (www.AstroDigi.com)
----- Original Message ----- From: "Hendra Agestha Hamid" <the_agestha@yahoo.com> To: <belajar-access@yahoogroups.com> Sent: Wednesday, July 06, 2011 9:59 AM Subject: Re: [belajar-access] Revisi Hasil eksperimen
Maaf Heru kmrn saya coba mau jawab cuma karena newbie jadi gak pede... Daripada saya nerangin salah berikut saya coba copas dari Help Access, saya pikir cukup jelas., tambahan lagi untuk field yang foreign key pada relationships harus di index Yes/Duplicate OK., selebihnya para pakar mungkin lebih punya pengalaman nyata.
An index helps Microsoft Access find and sort records faster. Access uses indexes in a table as you use an index in a book: to find data, it looks up the location of the data in the index. You can create indexes based on a single field or on multiple fields. Multiple-field indexes enable you to distinguish between records in which the first field may have the same value. Deciding which fields to index You'll probably want to index fields you search frequently, fields you sort, or fields that you join to fields in other tables in queries. However, indexes can slow down some action queries such as append queries, when the indexes for many fields need to be updated while performing these operations. The primary key of a table is automatically indexed, and you can't index a field whose data type is OLE Object. For other fields, you should consider indexing a field if all the following apply: * The field's data type is Text, Number, Currency, or Date/Time. * You anticipate searching for values stored in the field. * You anticipate sorting values in the field. * You anticipate storing many different values in the field. If many of the values in the field are the same, the index may not significantly speed up queries.
Multiple-field indexes If you think you'll often search or sort by two or more fields at a time, you can create an index for that combination of fields. For example, if you often set criteria for LastName and FirstName fields in the same query, it makes sense to create a multiple-field index on both fields. When you sort a table by a multiple-field index, Microsoft Access sorts first by the first field defined for the index. If there are records with duplicate values in the first field, Microsoft Access sorts next by the second field defined for the index, and so on. You can include up to 10 fields in a multiple-field index.
________________________________ From: Heru Wibowo <heru.wibowo4456@gmail.com> To: belajar-access@yahoogroups.com Sent: Wed, July 6, 2011 8:06:17 AM Subject: Re: [belajar-access] Revisi Hasil eksperimen
Waduh....topik ini sudah ditutup yah.....koq ndak ada yang nanggepin sama sekali yah? atau mungkin baru pada eksperiment untuk diatas 28 user ?
2011/7/5 Heru Wibowo <heru.wibowo4456@gmail.com>
men-cuplik ...hehee...istilah aja bang Nino....pada salah satu paragraf : > >Keempat: >Hal lain yang menentukan kecepatan adalah: tingkat optimalisasi kita sebagai >developer dalam mengoptimalkan proses normalisasi database. Rendudancy data >yang rendah dan indexing yang tepat akan sangat berpengaruh pada peningkatan >kecepatan proses. > >bla..bla..bla.... > >terus terang sangat kagum, 28 user tapi speed masih bagus....kalau bang Nino >berkenan....mohon bocoran ilmunya ( saya pake 5 user aja udah lemot) >salah satunya : bentuk normalisasi yang seperti diatas itu gambaranne kayak apa >yah ? >maksud saya dari jenis-jenis field pada suatu tabel, hal apa aja yang kira - >kira perlu dilakukan indexing, dan yang tabu dilakukan ? > >Demikian, atas masukan dari bang Nino diucapkan terima kasih. > >Salam, >HerDja > > > >2011/7/5 Nino Guevara Ruwano <nino@astrodigi.com> > > >> >>Link Table mas, dipakai di program penjualan, ke 28 user adalah >>kasir/penerima order yang aktif menginput data pembelian. >> >>Rgds, >> >>Nino >> >>----- Original Message ----- >>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com> >>To: <belajar-access@yahoogroups.com> >> >>Sent: Monday, July 04, 2011 12:27 PM >>Subject: RE: [belajar-access] Revisi Hasil eksperimen >> >>Wah memang beruntung bergabung dengan Milis...nambah terus euy ilmunya >>dari >>Share rekan2. >> >>Menarik sekali dengan pengalaman Mas Nino yg menemukan BE Access tdk turun >>performnya bila dipakai di Jaringan+Multi User, >>28 user lagi, hal ini tentu berbeda dari "teori" yg saya baca (lha belum >>pernah >>nyoba sendiri....) dan juga berbeda dengan pengalaman >>dari Mas Heru Wibowo ...Halo mas Heru) yg disampaikan di e mail sebelum >>ini...duh tambah pusing hasil pengalaman beda2 nih.. hahaha... >>Btw itu yg 28 user koneksinya pakai apa mas..? Link Table atau connection >>string..? >> >>Regards >>Hendra >> >>________________________________ >>From: Nino Guevara Ruwano <nino@astrodigi.com> >>To: belajar-access@yahoogroups.com >>Sent: Mon, July 4, 2011 9:10:53 AM >>Subject: Re: [belajar-access] Revisi Hasil eksperimen >> >>Dear Mas Hendra, >> >>Terima kasih atas informasinya, sebagai catatan tambahan dari pengalaman >>saya dalam implementasi. >> >>Pertama: >>BE MS Access nggak drop karena dipakai oleh lebih dari 1 user kok, saya >>sudah implementasikan dalam jaringan yang dipakai oleh 28 user sekaligus >>yang semuanya berfungsi sebagai kasir penerima order, hasilnya tetep bisa >>jalan secepat kilat. >> >>Kedua: >>BE MS Access baru menurun kecepatannya pada record yang sudah puluhan ribu. >>Ini terjadi pada program parkir yang sudah saya implementasikan di sebuah >>mall di Bogor. Dalam sehari transaksi bisa mencapai ribuan, sehingga ratusan >>ribu transaksi bisa tercapai hanya dalam 3 atau 4 bulan saja. >> >>Bisa diatasi dengan membuat program yang menutup transaksi setiap bulannya >>dan memindahkan transaksi bulan lalu kedalam database baru yang dijadikan >>backup. >> >>Pada client lain yang transaksinya besar, saya pindahkan datanya ke SQL >>Server. Hasilnya seperti yang saya sudah sampaikan pada email sebelumnya, >>kecepatan load data sedikit menurun (hanya saat awal buka form) tapi stabil >>dan tidak perlu compact & repair. >> >>Ketiga: >>Compact & Repair. Ini adalah masalah yang jadi krusial dan menurut saya ini >>jadi salah satu kelemahan BE MS Access. Karena pada BE yang sudah berukuran >>>300MB dalam puluhan kali compact & repair selalu saja ada satu saat dimana >>data rusak, entah tidak bisa dibuka atau sebagian data hilang. >> >>Harap masalah ini jadi pertimbangan penting bagi rekan2 yang membangun >>system dengan jumlah record besar dan kapasitas besar. >> >>Mungkin harus dibuat experimen tersendiri untuk mencari penyebab utama dan >>juga solusi tepatnya. Saat ini saya belum punya cukup waktu untuk >>berexperiman disini :) >> >>Keempat: >>Hal lain yang menentukan kecepatan adalah: tingkat optimalisasi kita sebagai >>developer dalam mengoptimalkan proses normalisasi database. Rendudancy data >>yang rendah dan indexing yang tepat akan sangat berpengaruh pada peningkatan >>kecepatan proses. >> >>Pada sebuah kasus pada client di Tangerang yang sempat saya tangani dengan >>engkong access (mas Lusky) kita sempat temukan FE yang dibangun dengan >>Delphi yang konon adalah system aplikasi tercepat , ternyata kecepatannya >>sangat jauuuuuuuuh tertinggal dengan aplikasi yang dibangun dengan MS >>Access, penyebabnya ya itu tadi . . normalisasi yang nggak optimal mas . >>.Delphi nggak optimal VS MS Access yang optimal, ya jelas jadi cepetan MS >>Accessnya :) >> >>OK mas Hendra, demikian review dan sharing dari saya semoga berguna untuk >>anda dan juga warga milis yang lain. Terus berkarya, dan semoga sukses . . . >> >>Regards, >> >>Nino >>(www.AstroDigi.com) >> >>----- Original Message ----- >>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com> >>To: <belajar-access@yahoogroups.com> >>Sent: Sunday, July 03, 2011 9:00 AM >>Subject: Re: [belajar-access] Revisi Hasil eksperimen >> >>Dear Mas Nino,... >>Terima kasih Mas Nino, itu bisa saya lakukan karena gak bisa bikin >>aplikasinya >>... (..), saya betul2 newbie mas...mgkn karena belum pernah pakai >>makanya sebelum pakai saya cek and ricek dulu,.... >>Dibawah ini saya copas hasil browsing saya terhadap perbandingan2 antar BE, >>ada >>yg comment itu dari MVP SQL Server juga. >>Dari semua itu akhirnya saya berkesimpulan akhir : Pakailah BE Access Link >>Table >>method (utk FE Access) bila itu untuk single user dan tdk >>di local station tdk di jaringan, dijamin lebih cepat dan saya sudah >>buktikan >>sendiri. >> >>Sebab utamanya kenapa jangan dipakai pada jaringan dan multi user adalah Jet >>Access pada BE drop bila dipakai lebih dari 1 user (saya gak bisa buktikan >>langsung tapi saya percaya banget soalnya yg ngomong para MVP ). >>Tapi kemudian satu lagi saya langsung sadar setelah saya baca pengalaman mas >>Nino,...dan ini mungkin juga jadi pertimbangan penting yaitu BE Access >>harus sering2 di Compact n Repair,,,(setau saya MYSQL dan SQL Server tdk >>perlu >>ini) ...terima kasih Mas Nino,,,pengalaman Mas bener2 berguna sebagai >>pertimbangan lainnya. >> >>Regards >>Hendra >> >>Berikut saya copas hasil browsing saya : >> >>I think Albert Kallal's comment is right, and the fact is that if you have >>a >>single-user app running on a single workstation (Access client with SQL >>Server >>running on the same workstation as a client), it will quite often be slower >>than if the setup on that workstation were Access client to Jet/ACE back >>end on >>the same machine. SQL Server adds a lot of overhead that delivers no >>benefit >>when there is no network in between the client and the SQL Server. >>The performance equation flips when there's a network involved, even for a >>single-user app. If the Access client runs on a workstation, and the SQL >>Server >>on a server on the other end of a network connection (even a fast one), it >>will >>likely be faster than if the data is stored in a Jet/ACE file on a file >>server. >> >>But it's not a given, in my opinion. It depends entirely on the engineering >>of >>the application and the excellence of the schema. >> >>Lainnya : >>Performance questions are very difficult to >>answer up front, because there are so many "it depends". What I can >>say, is that if you do this in Access, you should do it in a local >>Jet database, not not a linked SQL Server table. >> >>If you ask me to place my bets, I put them on Access for this one. >>String processing is not SQL Server's best game. >> >>________________________________ >>From: Nino Guevara Ruwano <nino@astrodigi.com> >>To: belajar-access@yahoogroups.com >>Sent: Sun, July 3, 2011 7:56:32 AM >>Subject: Re: [belajar-access] Revisi Hasil eksperimen >> >>Dear Mas Hendra, >> >>Sebelumnya saya ucapkan terimakasih atas usaha anda dalam melakukan >>experimen perbandingan data dengan BE berlainan tersebut. Salut! dan sangat >>membantu warga milis dalam membangun database system dikemudian hari. >> >>Sedikit urun pengalaman, saya pernah menggunakan BE MS Access yang kemudian >>terpaksa saya pindahkan ke SQL Server karena setelah record mencapai puluhan >>ribu (saat itu sudah 38ribu lebih) pengambilan data ke BE MS Access menjadi >>lambat, baru agak cepat kembali bila kita melakukan compact and repair pada >>BE >> >>Dalam sehari user harus melakukan compact and repair yang memakan waktu >>sekitar 5 menitan agar kecepatan tetap bagus, akhirnya saya pindahkan semua >>data ke SQL Server dan hasilnya memang SQL server butuh waktu 2 detik lebih >>lama untuk menampilkan data tapi stabil, dan user tidak direpotkan dengan >>compact and repair berulang2 >> >>Bahaya yang timbul dari proses compact and repair adalah kerusakan data, >>entah kenapa sampai dengan MS Access 2010 lahir dalam puluhan kali compact >>and repair pasti ada aja sekali waktu dimana database rusak, meskipun saya >>selalu melakukan backup tetapi masalah seperti ini cukup merisaukan. >> >>Coba mas Hendra uji lagi BE anda dengan beban record 30ribuan mas, mungkin >>hasilnya bisa berbeda. Untuk BE MySQL saya belum pernah coba dengan FE MS >>Access, biasanya saya gunakan PHP untuk FEnya. >> >>Sekali lagi salut buat mas Hendra yang bersedia meluangkan waktunya untuk >>experimen ini, keep going mas . . sukses ya >> >>Regards, >>Nino >> >>----- Original Message ----- >>From: "Hendra Agestha Hamid" <the_agestha@yahoo.com> >>To: <belajar-access@yahoogroups.com> >>Sent: Saturday, July 02, 2011 11:02 AM >>Subject: [belajar-access] Revisi Hasil eksperimen >> >>> Dear warga Milis,... >>> >>> Mohon maaf, setelah saya ulang2 lagi seluruh hasil eksperimen saya, >>ternyata >>> untuk membuka Form Source LT to MySQL mau >>> terbuka alias tidak hang, cuma butuh waktu agak lama, kemudian move last >>juga >>> cukup sebentar (move last sekitar 5 detik) >>> Yang LT to SQL server buka Form cepat tapi move last lama sekali (sekitar >>1 >>> menit). >>> Tapi tetap dibanding keduanya di atas masih lebih cepat yang Source LT to >>Mdb, >>> baik buka Form maupun move lastnya. >>> >>> Regards >>> Hendra >>> >> >> > > >-- >HerDja > >
-- HerDja
|
Tidak ada komentar:
Posting Komentar