_____ From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of ricky_uki Sent: 16 Januari 2007 9:20 To: [email protected] Subject: [indoprog-vb] Masalah dengan Point of sale Teman2 tolong bantu saya. saya membuat program POS saat ini dalam masa uji coba. program sudah digunakan selama 1 bulan. saya buat dengan VB 6, database MySQL.
permasalahannya saat lihat laporan baik laporan harian,bulanan dan stok aksesnya lama sekali (laporan tidak pernah berhasil dilihat). programnya seperti hank tapi komputer tidak hank. padahal saya uji pertama kali tidak selama itu. komp yang saya gunakan p4 1,8G dg winXP. setelah saya lihat dalam 1 bulan itu terjadi 5 ribuan transaksi dengan jumlah item yang terjual hampir 10 ribuan. >> data sebesar itu MySQL masih bisa cover, so ga masalah seharusnya dengan ukuran sebesar itu pertanyaan: 1. apa karena terlalu banyaknya transaksi yang menyebabkan program yg saya buat jadi seperti itu ? soalnya waktu saya coba langsung ngakses MySQL nya juga lama dan error karena waktunya habis. tapi kalo transaksinya sedikit aksesnya normal. >> biasanya terjadi kegagalan dari sisi driver, atawa koneksi ke server itu sendiri. Ada pernah temen saya juga ngalamin hal spt itu sampai saat ini ga ada solusi teknis yang tepat selain install ulang semuanya, baik Windows maupun MySQL server, tapi Anda jangan takut, install ulang database MySQL tidak serepot pada database komersil, untuk backup data Anda cukup copy folder Doc pada folder instalasi MySQL, pindahkan ke tempat lain data Anda sudah cukup aman. 2. gimana database(tabel) yang baik(akses cepat) untuk program POS ? >> tabel tidak terlalu masalah asalkan tidak terjadi redudancy data, program POS merupakan program murni database sehingga operasi yang dilakukan dari itu ke itu saja, saya sarankan untuk menggunakan Store Procedure, kenapa saya sarankan itu, coba Anda cari tau kenapa. Selain hal itu, teknik query juga harus bener2 dipahami untuk lebih dapat mendapatkan hasil yang maksimal, karena kita tahu teknik query seseorang pasti berbeda sesuai tingkat kemampuan, itu sangat membantu dalam masalah kecepatan yang kita harapkan permasalahan kedua, no faktur penjualan saya buat dengan 6 digit. kalo saya lihat transaksi yg selalu banyak tiap bulannya no faktur tsb akan cepat habis (no 999999) dan no akan kembali ke 000001 lagi. itu artinya no faktur akan bentrok. 1. bagaimana menyelesaikan masalah tsb ? >>penyelesaiannya ada dipihak Anda sendiri, karena Anda yang lebih tau permasalahannya, Mungkin bisa mengganti format no faktur dengan format baru, apakah itu memperlebar field atau logika penomorannya. Atau pada saat validasi Anda tidak hanya memeriksa no faktur yg ada ditabel, tetapi juga memerika no faktur dan tanggal, misalnya selama no faktur tersebut berbeda tanggal, tetep bisa asal jangan set sebagai primary key aja. 2. bagaimana membuat nomor faktur yg baik? >>pada dasarnya semua cara pembuatan no faktur itu baik, tergantung implementasinya bagaimana, besar data, jumlah transaksi, kebutuhan. Dari awal Anda harus memperkirakan besar transaksi yang terjadi, baik itu per hari, bulan dan tahun sehingga kita bisa mengetahui. Kalo saya sendiri untuk menghindari terjadinya hal seperti yang Anda alami selalu membuat no faktur seperti membuat no surat 3. atau ada cara lain ? mohon bantuan teman2 semuanya dan terima kasih sebelum dan sesudahnya. [Non-text portions of this message have been removed]
