Parafrase:
Tampaknya yang Anda inginkan adalah semacam sistem di mana mungkin ada dua (atau lebih) utas yang bekerja. Satu utas akan sibuk secara sinkron mengambil data dari database, dan melaporkan kemajuannya ke program lainnya. Utas lainnya akan berurusan dengan tampilan.
Tidak jelas apakah kueri Anda akan mengembalikan 500.000 baris (memang, semoga saja tidak), meskipun mungkin harus memindai semua 500.000 baris (dan mungkin hanya menemukan 23 baris yang cocok sejauh ini). Menentukan jumlah baris yang akan dikembalikan sulit; menentukan jumlah baris yang akan dipindai lebih mudah; menentukan jumlah baris yang sudah dipindai sangat sulit.
Jadi, pengguna telah menggulir melewati baris ke-23, tetapi kuerinya belum selesai.
Ada beberapa masalah di sini. DBMS (benar untuk sebagian besar database, dan tentu saja IDS) tetap terikat sejauh koneksi saat ini memproses satu pernyataan. Mendapatkan umpan balik tentang bagaimana kueri telah berkembang sulit. Anda dapat melihat perkiraan baris yang ditampilkan saat kueri dimulai (informasi dalam struktur SQLCA), tetapi nilai tersebut cenderung salah. Anda harus memutuskan apa yang harus dilakukan ketika Anda mencapai baris 200 dari 23, atau Anda hanya sampai ke baris 23 dari 5.697. Itu lebih baik daripada tidak sama sekali, tetapi itu tidak dapat diandalkan. Menentukan seberapa jauh kueri telah berkembang sangat sulit. Dan beberapa kueri memerlukan operasi pengurutan yang sebenarnya, yang berarti sangat sulit untuk memprediksi berapa lama waktu yang dibutuhkan karena tidak ada data yang tersedia hingga pengurutan selesai (dan setelah pengurutan selesai, hanya ada waktu yang dibutuhkan untuk berkomunikasi antara DBMS dan aplikasi untuk menahan pengiriman data).
Informix 4GL memiliki banyak keunggulan, tetapi dukungan thread bukanlah salah satunya. Bahasa tidak dirancang dengan mempertimbangkan keamanan benang, dan tidak ada cara mudah untuk memasangnya kembali ke dalam produk.
Saya pikir apa yang Anda cari akan paling mudah didukung oleh dua utas. Dalam program berulir tunggal seperti program I4GL, tidak ada cara mudah untuk keluar dan mengambil baris sambil menunggu pengguna mengetik beberapa masukan lagi (seperti 'menggulir ke bawah halaman berikutnya yang penuh dengan data').
Optimalisasi FIRST ROWS adalah petunjuk untuk DBMS; itu mungkin atau mungkin tidak memberikan manfaat yang signifikan terhadap kinerja yang dirasakan. Secara keseluruhan, ini biasanya berarti bahwa kueri diproses secara kurang optimal dari perspektif DBMS, tetapi memberikan hasil kepada pengguna dengan cepat dapat menjadi lebih penting daripada beban kerja pada DBMS.
Di suatu tempat di bawah dengan jawaban yang banyak dipilih, Frank berteriak (tapi tolong jangan BERTERIAK):
OKE. Kesulitannya di sini adalah mengatur IPC antara dua proses sisi klien. Jika keduanya terhubung ke DBMS, mereka memiliki koneksi terpisah, dan oleh karena itu tabel sementara dan kursor dari satu sesi tidak tersedia untuk sesi lainnya.
Tidak semua kueri menghasilkan tabel sementara, meskipun hasil yang ditetapkan untuk kursor gulir biasanya memiliki sesuatu yang kira-kira setara dengan tabel sementara. IDS tidak perlu menempatkan kunci pada tabel sementara yang mendukung kursor gulir karena hanya IDS yang dapat mengakses tabel. Jika itu adalah tabel temp biasa, masih tidak perlu menguncinya karena tidak dapat diakses kecuali oleh sesi yang membuatnya.
Mungkin pesan status yang lebih akurat adalah:
Searching 500,000 rows...found 23 matching rows so far
Mungkin; Anda juga bisa mendapatkan penghitungan cepat dan akurat dengan 'SELECT COUNT(*) FROM TheTable'; ini tidak memindai apa pun tetapi hanya mengakses data kontrol - mungkin secara efektif data yang sama seperti di kolom nrows tabel SMI sysmaster:sysactptnhdr.
Jadi, menelurkan proses baru jelas bukan resep untuk sukses; Anda harus mentransfer hasil kueri dari proses spawned ke proses asli. Seperti yang saya nyatakan, solusi multithreaded dengan tampilan terpisah dan utas akses basis data akan berfungsi setelah mode, tetapi ada masalah dengan melakukan ini menggunakan I4GL karena tidak sadar akan utas. Anda masih harus memutuskan bagaimana kode sisi klien akan menyimpan informasi untuk ditampilkan.
