Parafrazując:
Wygląda na to, że chciałbyś mieć jakiś system, w którym mogą działać dwa (lub więcej) wątki. Jeden wątek byłby zajęty synchronicznym pobieraniem danych z bazy danych i raportowaniem swojego postępu do reszty programu. Drugi wątek zajmowałby się wyświetlaczem.
Nie jest jasne, czy zapytanie zwróci 500 000 wierszy (miejmy nadzieję, że tak się nie stanie), chociaż może być konieczne przeskanowanie wszystkich 500 000 wierszy (i może do tej pory znaleźć tylko 23 pasujące wiersze). Określenie liczby wierszy do zwrócenia jest trudne; łatwiejsze jest określenie liczby wierszy do zeskanowania; określenie liczby już zeskanowanych wierszy jest bardzo trudne.
Tak więc użytkownik przewinął się do 23. wiersza, ale zapytanie nie zostało jeszcze zakończone.
Jest tu kilka problemów. DBMS (prawda większości baz danych, a na pewno IDS) pozostaje związany z bieżącym połączeniem podczas przetwarzania jednej instrukcji. Uzyskanie informacji zwrotnej na temat postępu zapytania jest trudne. Możesz spojrzeć na szacunkowe wiersze zwrócone podczas uruchamiania zapytania (informacje w strukturze SQLCA), ale te wartości mogą być błędne. Musiałbyś zdecydować, co zrobić, gdy dojdziesz do wiersza 200 z 23, czy tylko do wiersza 23 z 5697. To lepsze niż nic, ale nie jest niezawodne. Ustalenie, jak daleko posunęło się zapytanie, jest bardzo trudne. Niektóre zapytania wymagają rzeczywistej operacji sortowania, co oznacza, że bardzo trudno jest przewidzieć, jak długo to zajmie, ponieważ do zakończenia sortowania nie są dostępne żadne dane (a po zakończeniu sortowania jest tylko czas potrzebny na komunikację między DBMS i aplikację do wstrzymywania dostarczania danych).
Informix 4GL ma wiele zalet, ale obsługa wątków nie jest jedną z nich. Język nie został zaprojektowany z myślą o bezpieczeństwie gwintów i nie ma łatwego sposobu na dodanie go do produktu.
Myślę, że to, czego szukasz, najłatwiej byłoby wesprzeć dwoma wątkami. W programie jednowątkowym, takim jak program I4GL, nie ma łatwego sposobu, aby wyjść i pobrać wiersze podczas oczekiwania, aż użytkownik wpisze więcej danych wejściowych (takich jak „przewiń w dół następną stronę pełną danych”). /P>
Optymalizacja FIRST ROWS jest wskazówką dla DBMS; może, ale nie musi, dać znaczące korzyści dla postrzeganej wydajności. Ogólnie rzecz biorąc, zwykle oznacza to, że zapytanie jest przetwarzane mniej optymalnie z perspektywy DBMS, ale szybkie uzyskanie wyników dla użytkownika może być ważniejsze niż obciążenie pracą DBMS.
Gdzieś na dole w bardzo przegłosowanej odpowiedzi, Frank krzyknął (ale proszę nie KRZYCZ):
OK. Trudność polega na zorganizowaniu IPC między dwoma procesami po stronie klienta. Jeśli oba są połączone z DBMS, mają oddzielne połączenia, a zatem tymczasowe tabele i kursory jednej sesji nie są dostępne dla drugiej.
Nie wszystkie zapytania dają w wyniku tabelę tymczasową, chociaż zestaw wyników dla kursora przewijania zwykle ma coś w przybliżeniu równoważnego tabeli tymczasowej. IDS nie musi umieszczać blokady na tymczasowej tabeli wspierającej kursor przewijania, ponieważ tylko IDS może uzyskać dostęp do tabeli. Gdyby była to zwykła tabela tymczasowa, nadal nie byłoby potrzeby jej blokowania, ponieważ nie można uzyskać do niej dostępu z wyjątkiem sesji, która ją utworzyła.
Być może dokładniejszy komunikat o stanie to:
Searching 500,000 rows...found 23 matching rows so far
Prawdopodobnie; możesz również uzyskać szybkie i dokładne zliczanie za pomocą 'SELECT COUNT(*) FROM TheTable'; to niczego nie skanuje, ale po prostu uzyskuje dostęp do danych kontrolnych - prawdopodobnie faktycznie te same dane, co w kolumnie nrows tabeli SMI sysmaster:sysactptnhdr.
Tak więc tarło nowego procesu nie jest wyraźną receptą na sukces; musisz przenieść wyniki zapytania ze stworzonego procesu do pierwotnego procesu. Jak już wspomniałem, rozwiązanie wielowątkowe z oddzielnymi wątkami wyświetlania i dostępu do bazy danych działałoby w pewnym stylu, ale są problemy z robieniem tego przy użyciu I4GL, ponieważ nie jest on świadomy wątków. Nadal będziesz musiał zdecydować, w jaki sposób kod po stronie klienta będzie przechowywać informacje do wyświetlenia.
