Diễn giải:
Có vẻ như những gì bạn muốn là một loại hệ thống nào đó có thể có hai (hoặc nhiều) luồng đang hoạt động. Một luồng sẽ bận rộn tìm nạp đồng bộ dữ liệu từ cơ sở dữ liệu và báo cáo tiến trình của nó cho phần còn lại của chương trình. Chuỗi khác sẽ xử lý màn hình.
Không rõ ràng rằng truy vấn của bạn sẽ trả về 500.000 hàng (thực sự, chúng tôi hy vọng nó không), mặc dù nó có thể phải quét tất cả 500.000 hàng (và có thể chỉ tìm thấy 23 hàng phù hợp cho đến nay). Việc xác định số hàng được trả về là một việc khó; xác định số hàng được quét dễ dàng hơn; rất khó xác định số hàng đã được quét.
Vì vậy, người dùng đã cuộn qua hàng thứ 23, nhưng truy vấn vẫn chưa hoàn thành.
Có một số vấn đề ở đây. DBMS (đúng với hầu hết các cơ sở dữ liệu và chắc chắn là IDS) vẫn bị ràng buộc cho đến khi kết nối hiện tại xử lý một câu lệnh. Khó có được phản hồi về cách một truy vấn tiến triển. Bạn có thể xem các hàng ước tính được trả về khi bắt đầu truy vấn (thông tin trong cấu trúc SQLCA), nhưng những giá trị đó có thể sai. Bạn sẽ phải quyết định phải làm gì khi đến hàng 200 trên 23 hoặc bạn chỉ đến hàng 23 trên 5,697. Nó còn hơn không, nhưng nó không đáng tin cậy. Việc xác định xem truy vấn đã tiến triển đến đâu là rất khó. Và một số truy vấn yêu cầu thao tác sắp xếp thực tế, có nghĩa là rất khó dự đoán thời gian sẽ mất bao lâu vì không có dữ liệu nào cho đến khi việc sắp xếp được thực hiện (và một khi sắp xếp xong, chỉ có thời gian để giao tiếp giữa DBMS và ứng dụng để duy trì việc cung cấp dữ liệu).
Informix 4GL có nhiều ưu điểm, nhưng hỗ trợ luồng không phải là một trong số đó. Ngôn ngữ này không được thiết kế với sự lưu ý đến an toàn luồng và không có cách nào dễ dàng để bổ sung nó vào sản phẩm.
Tôi nghĩ rằng những gì bạn đang tìm kiếm sẽ được hỗ trợ dễ dàng nhất bởi hai luồng. Trong một chương trình đơn luồng như chương trình I4GL, không có cách nào dễ dàng để bắt đầu và tìm nạp các hàng trong khi chờ người dùng nhập thêm một số đầu vào (chẳng hạn như 'cuộn xuống trang tiếp theo đầy dữ liệu').
Tối ưu hóa ROWS ĐẦU TIÊN là một gợi ý cho DBMS; nó có thể mang lại hoặc không mang lại lợi ích đáng kể cho việc thực hiện được nhận thức. Nhìn chung, điều đó thường có nghĩa là truy vấn được xử lý kém tối ưu hơn theo quan điểm DBMS, nhưng việc đưa kết quả đến người dùng một cách nhanh chóng có thể quan trọng hơn khối lượng công việc trên DBMS.
Ở đâu đó bên dưới trong một câu trả lời bị bỏ phiếu thấp, Frank hét lên (nhưng xin đừng NÓI LÊN):
ĐƯỢC RỒI. Khó khăn ở đây là tổ chức IPC giữa hai quy trình phía máy khách. Nếu cả hai đều được kết nối với DBMS, chúng có các kết nối riêng biệt và do đó các bảng và con trỏ tạm thời của một phiên sẽ không khả dụng với phiên kia.
Không phải tất cả các truy vấn đều dẫn đến một bảng tạm thời, mặc dù tập kết quả cho con trỏ cuộn thường có một cái gì đó gần tương đương với một bảng tạm thời. IDS không cần đặt một ổ khóa trên bảng tạm thời hỗ trợ con trỏ cuộn vì chỉ IDS mới có thể truy cập bảng. Nếu đó là một bảng tạm thời thông thường, vẫn không cần phải khóa nó vì không thể truy cập nó ngoại trừ phiên đã tạo ra nó.
Có thể một thông báo trạng thái chính xác hơn sẽ là:
Searching 500,000 rows...found 23 matching rows so far
Có thể; bạn cũng có thể đếm nhanh và chính xác với 'SELECT COUNT (*) FROM TheTable'; điều này không quét bất cứ thứ gì mà chỉ truy cập dữ liệu điều khiển - có thể giống dữ liệu trong cột nrows của trình tổng hợp bảng SMI:sysactptnhdr.
Vì vậy, việc tạo ra một quy trình mới rõ ràng không phải là một công thức để thành công; bạn phải chuyển kết quả truy vấn từ quy trình được tạo thành quy trình ban đầu. Như tôi đã nêu, một giải pháp đa luồng với các luồng truy cập cơ sở dữ liệu và hiển thị riêng biệt sẽ hoạt động sau một thời gian, nhưng có vấn đề khi thực hiện việc này bằng I4GL vì nó không nhận biết được luồng. Bạn vẫn phải quyết định cách mã phía máy khách sẽ lưu trữ thông tin để hiển thị.
