Парафразиране:
Изглежда, че това, което бихте искали, е някаква система, в която може да има две (или повече) нишки на работа. Една нишка ще бъде заета да извлича синхронно данните от базата данни и да докладва напредъка си на останалата част от програмата. Другата тема ще се занимава с дисплея.
Не е ясно дали вашата заявка ще върне 500 000 реда (всъщност, нека се надяваме, че не е така), въпреки че може да се наложи да сканира всички 500 000 реда (и може да е намерил само 23 реда, които съвпадат досега). Определянето на броя на редовете за връщане е трудно; определянето на броя на редовете за сканиране е по-лесно; определянето на броя на вече сканираните редове е много трудно.
И така, потребителят е превъртил 23-ия ред, но заявката все още не е завършена.
Тук има няколко проблема. СУБД (вярно за повечето бази данни и със сигурност за IDS) остава обвързана до сегашната връзка при обработката на единия израз. Получаването на обратна връзка за напредъка на заявката е трудно. Можете да погледнете приблизителните редове, върнати при стартиране на заявката (информация в структурата на SQLCA), но тези стойности са склонни да бъдат грешни. Ще трябва да решите какво да правите, когато стигнете до ред 200 от 23, или ще стигнете само до ред 23 от 5697. По-добре е от нищо, но не е надеждно. Определянето докъде е напреднала заявката е много трудно. И някои заявки изискват действителна операция за сортиране, което означава, че е много трудно да се предвиди колко време ще отнеме, тъй като няма налични данни, докато сортирането не бъде извършено (а след като сортирането е направено, има само времето, необходимо за комуникация между СУБД и приложението за задържане на доставката на данните).
Informix 4GL има много предимства, но поддръжката на нишки не е едно от тях. Езикът не е проектиран с оглед на безопасността на нишките и няма лесен начин да го модернизирате в продукта.
Мисля, че това, което търсите, ще бъде най-лесно подкрепено от две нишки. В еднонишкова програма като I4GL програма, няма лесен начин да излезете и да извлечете редове, докато чакате потребителят да въведе още малко данни (като например „превъртете надолу следващата страница, пълна с данни“).
Оптимизацията на FIRST ROWS е намек за СУБД; може или не може да даде значителна полза за възприеманото изпълнение. Като цяло това обикновено означава, че заявката се обработва по-малко оптимално от гледна точка на СУБД, но бързото получаване на резултати за потребителя може да бъде по-важно от натоварването на СУБД.
Някъде по-долу в отговор с много отрицателно гласуване, Франк извика (но моля, не ВИКАТЕ):
ДОБРЕ. Трудността тук е организирането на IPC между двата процеса от страна на клиента. Ако и двете са свързани към СУБД, те имат отделни връзки и следователно временните таблици и курсори на една сесия не са достъпни за другата.
Не всички заявки водят до временна таблица, въпреки че наборът от резултати за курсора за превъртане обикновено има нещо приблизително еквивалентно на временна таблица. IDS не трябва да поставя заключване на временната таблица, поддържаща курсор за превъртане, тъй като само IDS има достъп до таблицата. Ако беше обикновена временна таблица, пак нямаше да има нужда да я заключвате, защото не може да бъде достъпна освен от сесията, която я е създала.
Може би по-точно съобщение за състоянието би било:
Searching 500,000 rows...found 23 matching rows so far
Вероятно; можете също да получите бързо и точно броене с 'SELECT COUNT(*) FROM TheTable'; това не сканира нищо, а просто осъществява достъп до контролните данни - вероятно ефективно същите данни като в колоната nrows на таблицата SMI sysmaster:sysactptnhdr.
Така че създаването на нов процес не е ясно рецепта за успех; трябва да прехвърлите резултатите от заявката от създадения процес към оригиналния процес. Както казах, многонишково решение с отделни нишки за дисплей и достъп до база данни би работило по някакъв начин, но има проблеми с това с I4GL, тъй като не е наясно с нишки. Все пак трябва да решите как кодът от страна на клиента ще съхранява информацията за показване.
