Parafraseando:
Parece que o que você gostaria é de algum tipo de sistema onde possa haver dois (ou mais) threads em funcionamento. Um thread estaria ocupado buscando os dados de forma síncrona do banco de dados e relatando seu progresso para o resto do programa. O outro segmento estaria lidando com a exibição.
Não está claro se sua consulta retornará 500.000 linhas (na verdade, esperemos que não), embora possa ter que varrer todas as 500.000 linhas (e pode muito bem ter encontrado apenas 23 linhas correspondentes até agora). Determinar o número de linhas a serem retornadas é difícil; determinar o número de linhas a serem verificadas é mais fácil; determinar o número de linhas já verificadas é muito difícil.
Portanto, o usuário passou da 23ª linha, mas a consulta ainda não foi concluída.
Há um par de questões aqui. O DBMS (verdadeiro na maioria dos bancos de dados e certamente no IDS) permanece vinculado à conexão atual no processamento de uma instrução. Obter feedback sobre como uma consulta progrediu é difícil. Você pode observar as linhas estimadas retornadas quando a consulta foi iniciada (informações na estrutura SQLCA), mas esses valores podem estar errados. Você teria que decidir o que fazer quando chegasse à linha 200 de 23, ou só chegaria à linha 23 de 5.697. É melhor que nada, mas não é confiável. Determinar o quanto uma consulta progrediu é muito difícil. E algumas consultas requerem uma operação de classificação real, o que significa que é muito difícil prever quanto tempo levará porque nenhum dado está disponível até que a classificação seja concluída (e uma vez que a classificação é concluída, há apenas o tempo necessário para a comunicação entre o SGBD e o aplicativo para atrasar a entrega dos dados).
O Informix 4GL tem muitas virtudes, mas o suporte a threads não é uma delas. A linguagem não foi projetada com a segurança da rosca em mente e não há uma maneira fácil de adaptá-la ao produto.
Eu acho que o que você está procurando seria mais facilmente suportado por dois tópicos. Em um programa de thread único como um programa I4GL, não há uma maneira fácil de ir buscar linhas enquanto espera que o usuário digite mais alguma entrada (como 'rolar para baixo na próxima página cheia de dados').
A otimização FIRST ROWS é uma dica para o DBMS; pode ou não dar um benefício significativo para o desempenho percebido. No geral, isso normalmente significa que a consulta é processada de maneira menos otimizada da perspectiva do DBMS, mas obter resultados rapidamente para o usuário pode ser mais importante do que a carga de trabalho no DBMS.
Em algum lugar abaixo em uma resposta muito votada, Frank gritou (mas por favor, não GRITE):
OK. A dificuldade aqui é organizar o IPC entre os dois processos do lado do cliente. Se ambos estiverem conectados ao DBMS, eles terão conexões separadas e, portanto, as tabelas e cursores temporários de uma sessão não estarão disponíveis para a outra.
Nem todas as consultas resultam em uma tabela temporária, embora o conjunto de resultados para um cursor de rolagem geralmente tenha algo aproximadamente equivalente a uma tabela temporária. O IDS não precisa colocar um bloqueio na tabela temporária apoiando um cursor de rolagem porque somente o IDS pode acessar a tabela. Se fosse uma tabela temporária regular, ainda não haveria necessidade de bloqueá-la porque ela não pode ser acessada, exceto pela sessão que a criou.
Talvez uma mensagem de status mais precisa seja:
Searching 500,000 rows...found 23 matching rows so far
Provavelmente; você também pode obter uma contagem rápida e precisa com 'SELECT COUNT(*) FROM TheTable'; isso não verifica nada, mas simplesmente acessa os dados de controle - provavelmente os mesmos dados da coluna nrows da tabela SMI sysmaster:sysactptnhdr.
Assim, gerar um novo processo não é claramente uma receita para o sucesso; você precisa transferir os resultados da consulta do processo gerado para o processo original. Como afirmei, uma solução multithread com exibição separada e threads de acesso ao banco de dados funcionaria de certa forma, mas há problemas em fazer isso usando I4GL porque não reconhece thread. Você ainda teria que decidir como o código do lado do cliente armazenará as informações para exibição.
