Meeting ke-4, sharing prakom makin terarah

Learning Clarion

Alhamdulillah, sesuai jadwal hari ini Rabu (17/2) teman-teman prakom BPS mengadakan meeting ke-4. Kali ini giliran ruang perpus kantor yang kita sambangi. Bertempat di Gedung Gress (4) Di lantai dasar, pojok, deket masjid, sharing clarion dilanjutkan. Pembahasan masih seputar membuat aplikasi sederhana di clarion. Kasus demi kasus mulai bermunculan, kali ini giliran esya [kaito_kid] yang punya masalah dengan menampilkan data di listbox.

Kasusnya, esya membuat aplikasi phone book sederhana yang terdiri dari 2 tabel. Tabel pertama berisi idbio, nama, dan alamat. Tabel kedua berisi idph, idbio, nomertelp. Kedua tabel direlasikan melalui field idbio. Masalah terjadi ketika esya menampilkan data tabel kedua, tapi kolom idbio secara langsung ditransformasikan ke kolom nama di tabel pertama. Hmmm, udah coba diotak-atik di listbox formater. Ndak bisa, coba di otak-atik di action juga belum bisa. Sampai akhirnya, kasus ini diskors karena belum ada yang bisa memecahkan. maklum lah, yang sharing masih blank semua soal clarion, jadi ya masih belajar merangkak bareng-bareng. Sementara ini, kita lebih sering meraba-raba. Bagaimana clarion bisa melakukan suatu hal yang biasa kita lakukan di pemrograman yang lain. Misal saja ketika membuat form update, ternyata di clarion sudah ada template yang bisa langsung kita pakai tanpa perlu ribet coding. Hanya perlu menset table yang dirujuk dan field-filednya ditampilkan di form. Tentu ini hanya berlaku di kasus sederhana, selanjutnya … ya begitulah

Pertemuan dilanjutkan dengan diskusi mengenai roadmap meeting. Yup, selama ini memang kita belum memiliki nara sumber yang bisa memberikan pencerahan. Adapun andrian, dari basis data, bulan-bulan ini masih aktif konsinasi terus. Sehingga belum ada kesempatan untuk sharing dengan teman-teman yang lain. Sharing pun akhirnya jalan dengan seadanya. Dari evaluasi pertemuan ke-2 dan ke-3 muncullah usulan untuk membuat tahap demi tahap yang harus kita capai agar pertemuan makin terarah. Insya Allah sebagai gambaran awal, telah disepakati dan disahkan oleh pak deputi [fajar] bahwa pertemuan Clarion akan dioptimalkan sampai bulan depan (maret). Adapun case yang akan jadi bahan diskusi adalah Aplikasi MFD yang dikelola oleh bagian metodologi. Dalam hal ini, mas arisss yang lebih paham. Karena memang di PKS lah, MFD ini sedang digarap. Kabarnya MFD Fix untuk SP2010 bakal keluar akhir bulan ini.

Pada sore tadi, kita baru sharing mengenai pembuatan database awalnya. Tabel dasar yang dibuat adalah tabel prop [kprop, nama]; kab [kprop, kkab, nama]; kec [kprop, kkab, kkec, nama]; desa [kprop, kkab, kkec, kdesa, nama]. Nagh, sebelumnya terjadi sedikit diskusi mengenai struktur tabel. karena sebelumnya mas ariss menampilkan data MFD yang “tumpuk undung”. Data dari mulai prop sampai tingkat desa ada dalam satu tabel yang diwujudkan langsung dengan id2009 yang berjumlah 10char. Dimana jika 8 char kosong dari belakang, atau 2 char depan isi maka itu adalah kode propinsi. Jika 6 char dibelakang kosong itu adalah kode kabupaten, jika 3 char dibelakang kosong itu adalah kecamatan dan akhirnya jika semua terisi itu adalah kode desa. Hal ini membuat beberapa teman bingung??? Apa mungkin tabel yang akan dibuat dengan wujud seperti ini. Diskusi pun kemudian muncul mengenai pengkodean. Apakah disatukan seperti itu, kemudian nanti digunakan format left, mid, right untuk mendapatkan kode yang diperlukan. Atau dipisah-pisah per item, persis seperti tabel dasar yang disebutkan di atas.

Setelah terjadi diskusi yang panjang, akhirnya ditemukan pokok masalahnya. Bahwa data yang dikeluarkan mas ariss tsb adalah data rekap untuk pelaporan, bukan untuk pengolahan updating.

Selanjutnya, pertanyaan muncul lagi dari mas udin [suchaini] yang sedikit berbeda pendapat mengenai “unique” value yang diset di key propinsi, kabupaten, kecamatan dan desa. Pertanyaan ini muncul ketika kita sedang membahas masalah key di clarion. FYI, key di clarion itu tidak melulu untuk primary dan foreign key saja, tp juga bisa berlaku sebagai key untuk sorting. Contoh kasusnya seperti ini, dalam tabel kabupaten [kab] ada field kkab, kemudian juga ada key KeyKab yang sebenarnya keduanya sangat jelas berbeda. kkab tidak harus unique! Hal ini karena bisa jadi kode kabupaten bisa sama, misal 3171 untuk kota x dan 5171 untuk kota z. Keduanya memiliki entrian 75 di field kkab. Sedang yang dimaksud unique dalam kasus ini adalah KeyKab yang terdiri dari kprop dan kkab, misalnya ya 3171 dan 5171

Meeting pun harus diakhir karena jam sudah menunjukkan pukul 6 sore lewat. *jam perpus ngaco sih, jadi pada gak nyadar*. Pertemuan pun akhirnya ditutup dengan informasi pengumpulan kas 5ribuan/pertemuan oleh pak deputi. Insya Allah pertemuan ke-5 besok masih di perpus. Mau ikut? Come join with us… sinau bareng.

FYI, daftar hadir pertemuan kali ini

1. Fajar [deputi]
2. Prima [ajib19]
3. Esya [kaito_kid]
4. Kurnia [kuro]
5. Wawan
6. Echi
7. Aris [arisss]
8. Udin [suchaini]
9. Rieka

adapun juga 2 peserta yang hadir kemudian kabur ditengah pertemuan

1. Mas Iskandar
2. Yogi

Popularity: 6% [?]