Senin, 11 Juli 2011

Re: [belajar-access] Revisi Hasil eksperimen

 

Hmmh...kalo sama perilakunya mending bikin query aja,,,hehehehe...(cari yg gak mumet),,,
Yang Northwind gimana kalo bertahap aja mas..? Tahap pertama versi VBA pure nanti versi kedua pake SP, dengan gitu kita tambah ngeh
maksudnya kemudian bisa kita bandingkan sendiri masing2 metode (Original Nwind, NWind+VBA, NWind+VBA+SP),,,
Tapi capek juga ngerjainnya ya mas...hehehehe

Regards
Hendra


From: hari yanto <har_i20002000@yahoo.com>
To: belajar-access@yahoogroups.com
Sent: Monday, July 11, 2011 9:52 AM
Subject: Re: [belajar-access] Revisi Hasil eksperimen

 
--- On Sun, 10/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: Sunday, 10 July, 2011, 9:10 AM

 
Aduh senengnya Mas Hari mau ikut bantu...

Mas tentang tarik menarik data nih, berkaitan dengan perilaku access yg menarik seluruh data ke memory client baru kemudian
di filter di client, contoh :

SELECT [T_DIKLAT].NamaDiklat
FROM [T_DIKLAT]
WHERE ((([T_DIKLAT].NamaDiklat) Is Not Null));

Apakah perilaku itu tetap terjadi bila kita tuliskan Sql expression itu di VBA ?
 
Ya... Hanya di VBA harus kita sesuaikan. Misalnya menjadi
"SELECT T_DIKLAT.NamaDiklat
FROM T_DIKLAT WHERE T_DIKLAT.NamaDiklat Is Not Null"

ataukah perilaku itu hanya bila kita memakai Query Access ?
(Btw tetep ditunggu ya mas Northwindnya...hehehehe...ooops bocoran nih...:)) laughing)
 
Untuk northwind-nya, masih dalam proses. Insyallah dalam waktu dekat akan saya selesaikan. Kalau terpaksa, saya pakai VBA biasa. Tanpa Store Prosedure (SP) yang di tanam di MySql (saya sih ingin sekali praktek SP).
 
 
Regards
Hendra


From: hari yanto <har_i20002000@yahoo.com>
To: belajar-access@yahoogroups.com
Sent: Sunday, July 10, 2011 7:46 AM
Subject: Re: [belajar-access] Revisi Hasil eksperimen

 
Ikutan...
 
Menurut saya, Query di Ms Access adalah cara gampang membuat SQL. Untuk mengetahui SQL dari query yang telah kita buat:
  1. design view query yang akan kita lihat SQLnya
  2. klik View
  3. 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












__._,_.___
Recent Activity:
SPAM IS PROHIBITED
.

__,_._,___

Tidak ada komentar:

Posting Komentar