Bisa coba tolong berikan contoh query yang bermasalah?
Kemudian apakah sudah ada primary index?

Untuk masalah penomoran, kalo saya sih saya kasih lebar fieldnya 20, agar
leluasa untuk perubahan penomoran. Jika dirasa 4 digit kurang, maka bisa
langsung ubah jadi 5 digit tanpa rubah aplikasi, paling untuk perbaikinya
cukup ubah dari query untuk tambahkan digit 0 di depannya.
Namun sebaiknya untuk semua penomoran faktur jangan dipergunakan sebagai
primary key, dan tambahkan 1 kolom khusus bertipe integer yang dijadikan
sebagai primary key, sehingga di mungkinkan terjadinya perubahan pada
penomoran faktur.

Nomor faktur memang sebaiknya mempergunakan format penomoran yang spesifik,
misalnya tambahkan informasi bulan dan tahun, jadi nomor di reset per bulan
dan per tahun. Kemudian tambahkan misalnya per counter atau dokumen
tertentu.

Iwan Cahyadi Sugeng
Freelance Programmer

Interaktif Cipta Lestari
Jakarta - Indonesia

Yahoo ID: gig_boy2001
MSN ID  : iwancs
 

> -----Original Message-----
> From: ERIS RISO [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, January 16, 2007 10:40 AM
> To: [email protected]
> Subject: RE: [indoprog-vb] Masalah dengan Point of sale
> 
>   _____  
> 
> 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.
>  

Kirim email ke