Parafráze:
Zdá se, že byste chtěli nějaký systém, kde mohou fungovat dvě (nebo více) vláken. Jedno vlákno by bylo zaneprázdněno synchronním načítáním dat z databáze a hlášením jeho průběhu zbytku programu. Druhé vlákno by se zabývalo displejem.
Není jasné, že váš dotaz vrátí 500 000 řádků (opravdu doufejme, že ne), i když možná bude muset prohledat všech 500 000 řádků (a možná zatím našel pouze 23 odpovídajících řádků). Určení počtu řádků, které mají být vráceny, je obtížné; určení počtu řádků ke skenování je jednodušší; určení počtu již naskenovaných řádků je velmi obtížné.
Uživatel tedy přešel přes 23. řádek, ale dotaz ještě není dokončen.
Je zde několik problémů. DBMS (pravda pro většinu databází a určitě i pro IDS) zůstává svázána, pokud jde o aktuální spojení při zpracování jednoho příkazu. Získání zpětné vazby o tom, jak dotaz postupoval, je obtížné. Můžete se podívat na odhadované řádky vrácené při spuštění dotazu (informace ve struktuře SQLCA), ale tyto hodnoty mohou být chybné. Museli byste se rozhodnout, co dělat, když dosáhnete řádku 200 z 23, nebo se dostanete pouze na řádek 23 z 5 697. Je to lepší než nic, ale není to spolehlivé. Určit, jak daleko dotaz pokročil, je velmi obtížné. A některé dotazy vyžadují skutečnou operaci řazení, což znamená, že je velmi těžké předpovědět, jak dlouho to bude trvat, protože do dokončení řazení nejsou k dispozici žádná data (a jakmile je řazení dokončeno, zbývá pouze čas, který zabere komunikaci mezi DBMS a aplikace pro zdržení doručení dat).
Informix 4GL má mnoho předností, ale podpora vláken mezi ně nepatří. Jazyk nebyl navržen s ohledem na bezpečnost vláken a neexistuje žádný snadný způsob, jak jej do produktu dodatečně namontovat.
Myslím si, že to, co hledáte, by nejsnáze podpořily dvě vlákna. V programu s jedním vláknem, jako je program I4GL, neexistuje snadný způsob, jak odejít a načíst řádky, zatímco čekáte, až uživatel zadá nějaký další vstup (například „přejděte na další stránku plnou dat“). /P>
Optimalizace FIRST ROWS je nápovědou pro DBMS; může, ale nemusí přinést významný přínos vnímanému výkonu. Celkově to obvykle znamená, že dotaz je z pohledu DBMS zpracován méně optimálně, ale rychlé získání výsledků k uživateli může být důležitější než pracovní zátěž na DBMS.
Někde dole v odpovědi, která byla hodně záporná, Frank zakřičel (ale prosím nekřičte):
OK. Obtíž je zde organizovat IPC mezi dvěma procesy na straně klienta. Pokud jsou oba připojeni k DBMS, mají samostatná připojení, a proto dočasné tabulky a kurzory jedné relace nejsou dostupné pro druhou.
Ne všechny dotazy vedou k dočasné tabulce, ačkoli sada výsledků pro posuvný kurzor má obvykle něco přibližně ekvivalentního dočasné tabulce. IDS nemusí umístit zámek na dočasnou tabulku podporující posuvný kurzor, protože k tabulce má přístup pouze IDS. Pokud by to byla běžná dočasná tabulka, stále by nebylo potřeba ji zamykat, protože k ní nelze přistupovat jinak než pomocí relace, která ji vytvořila.
Možná by přesnější stavová zpráva byla:
Searching 500,000 rows...found 23 matching rows so far
Pravděpodobně; můžete také získat rychlé a přesné počítání pomocí 'SELECT COUNT(*) FROM TheTable'; to nic neskenuje, ale pouze přistupuje k řídicím datům – pravděpodobně fakticky stejným datům jako ve sloupci nrows tabulky SMI sysmaster:sysactptnhdr.
Vytvoření nového procesu tedy není jasným receptem na úspěch; musíte přenést výsledky dotazu z vytvořeného procesu do původního procesu. Jak jsem uvedl, vícevláknové řešení se samostatným zobrazením a vlákny pro přístup k databázi by po určité době fungovalo, ale při použití I4GL existují problémy, protože není vědomé vláken. Stále byste se museli rozhodnout, jak bude kód na straně klienta ukládat informace pro zobrazení.