Visual FoxPro 7.0 HON NA LIŠKU Začněme obligátní rekapitulací: jak dlouho to je, kdy byl naposledy v Chipu uveden článek o FoxPro? Kdybychom soudili podle čtenářských ohlasů, tak pradávno - do redakce přicházejí občas připomínky, které svědčí o neuspokojeném zájmu. Ve skutečnosti jsou to však pouhé dva roky, kdy jsme na stránkách čísla 5/99 hodnotili připravenost FoxPro na rok 2000 a seznamovali se s vlastnostmi tehdejší novinky - Visual FoxPro 6.0. Onehdy jsme také komentovali postavení Visual FoxPro mezi podobnými softwarovými produkty a vůbec jsme se vraceli k historické cestě, na níž u nás i ve světě tento zajímavý vývojový databázový nástroj provázely pomluvy i obdiv. Letošek přináší novou verzi - Visual FoxPro 7.0 -, které se v Microsoftu říká "Sedona". Zatím tedy v Microsoftu pokračuje móda dávat interně novým produktům jména podle amerických i neamerických měst - i městeček. Sedona je totiž neveliké malebné turistické centrum na úpatí hor v Arizoně. Když už jsme o přezdívky zavadili, neodpustím si poznámku o levé ruce, která neví, co dělá pravá: minulá verze Visual FoxPro dostala název "Tahoe" (což je vůbec zapadlé místo) a stejné jméno Microsoft použil pro svůj chystaný server s oficiálním názvem Microsoft SharePoint Portal Server. Kam běžíš, liško? FoxPro více než jiné softwarové produkty (pokud se vůbec dočkaly tak dlouhého života) přitahuje pozornost kvůli rozporuplnosti, která tento vývojový nástroj několik let provází: na jedné straně je často zmiňována jeho nejistá budoucnost, na straně druhé jsou vyzdvihovány jeho vynikající technické vlastnosti. Je obtížné FoxPro jednoznačně zařadit do dnešních škatulek pro softwarové prostředky. Záběr jeho využití je příliš široký, což dělá problémy i Microsoftu, když má stanovit pro tento svůj produkt pozici jednoduchým sloganem. A tak je běžné, že odborníci FoxPro jednou srovnávají s databázovými prostředky, jako jsou SQL Server či Informix, a jindy s vývojovými nástroji, jako jsou Visual Basic či Delphi. FoxPro v sobě přitom má od každého něco a pro mnohé aplikace je tato šíře použitelnosti optimální. Toho využívají tisíce programátorů u nás a celosvětově asi 500 000 vývojářů. Pokud tato čísla někomu připadají nevýrazná (např. ve srovnání s uváděnými počty uživatelů Visual Basicu, kterých je světě několik milionů), připomeňme jeden důležitý rozdíl: většinu vývojářů, kteří programují ve FoxPro, je možné považovat za profesionály, protože se programováním živí. Nic podobného se ovšem určitě nedá říci o oněch milionech "programátorů", kteří programují ve Visual Basicu. Nedávným příspěvkem k tomu, aby rozporuplnost provázející FoxPro neztratila dech, se stalo oznámení Microsoftu o vizích pro příští generace softwarových aplikací. Microsoft v červnu 2000 ohlásil nástup nové platformy označované Microsoft .NET Platform. Pro budování softwarové infrastruktury informačních systémů vzniká řada serverů, kterým se říká .NET servery (sem patří např. BizTalk Server 2000, ale i nové verze již zaběhaných serverů, jako jsou Exchange či SQL Server). Zároveň Microsoft naznačil, v jakém prostředí se mají nové aplikace vytvářet: jde o takzvaný .NET Framework. A vývojovým nástrojem pro vytváření aplikací nové generace se stane nově koncipované Visual Studio.NET. Právě zpráva o vývojovém nástroji však byla poněkud v rozporu s očekáváními vývojářů. Ti do té doby počítali s tím, že nejbližší verze Visual Studia s číslem 7.0 se dočkají v souladu s dřívějšími zprávami v závěru roku 2000 (jako součást Visual Studia 7.0 byla ohlašována také nová verze Visual FoxPro - 7.0). Šlo tedy o to odhalit, zda půjde jen o přejmenování Visual Studia 7.0 na Visual Studio.NET, nebo o něco více. První důrazné objasnění situace nastalo na podzim 2000. Microsoft nejspíš dospěl k přesvědčení, že sousto .NET je příliš velké a že Visual Studio.NET znamená změny od samého základu, protože posunul termín uvedení na trh: Visual Studio.NET nebude na světě dříve než na podzim 2001. Jaký vliv mají tyto skutečnosti na Visual FoxPro? Ještě v září 2000 Microsoft oznamoval, že Visual FoxPro 7.0 bude součástí Visual Studia.NET, ale nedojde k plné integraci s platformou .NET: Visual FoxPro nebude například používat runtime (CLR), který bude společný pro C# (programovací jazyk nové generace) a Visual Basic.NET. Celý rozruch kolem vztahu Visual FoxPro 7.0 - Visual Studio.NET vyvrcholil v únoru 2001 oznámením Microsoftu, že Visual FoxPro 7.0 nebude dále čekat na dokončení Visual Studia.NET a začne se dodávat již na konci jara 2001. Jelikož oficiální ohlášení Microsoftu se zatím odehrálo pouze na jeho webu, bylo by jistě pro všechny domácí foxaře užitečné využít bezprostřednější zdroj. Bude k tomu příležitost: na domácí červnové konferenci Visual FoxPro DevCon, Praha 2001 má vystoupit Randy Brown (Program Manager Visual FoxPro Team, Microsoft, USA), od něhož se očekávají bližší informace. Po zkušenostech se způsobem, jak v minulosti informovala o Visual FoxPro evropská zastoupení Microsoftu, by si foxaři neměli nechat ujít možnost získat informace z první ruky. Více informací o této konferenci najdete v tomto čísle v sekci "Aktuality: spektrum" nebo na adrese [2]. Jedna věc je však jistá: Visual FoxPro 7.0 je verze, kterou brzy začneme používat, a tak se podívejme, co zajímavého přináší. Co je nového v sedmičce? O tom, co nového Visual FoxPro 7.0 předvede, se mluví již déle než dva roky: nejprve jen v opatrných náznacích o IntelliSense a editoru, potom o spolupráci s COM+ a jiných změnách. Dnes je už jasné, že Visual FoxPro 7.0 obsahuje navíc také spousty na první pohled přehlédnutelných drobností, které by bylo škoda nevyužít. Hlavní oblasti, které byly v nové verzi Visual FoxPro vylepšeny, jsou následující: programátorské prostředí; funkčnost datového slovníku; možnost automatického testování aplikací; spolupráce s COM+; existence ovladače OLE DB pro data Visual FoxPro; obohacení funkcí pro práci s poli a řetězci. Tento článek není přehledem o všech inovacích, ale je počátkem seriálu věnovaného Visual FoxPro 7.0, který bude pokračovat v budoucích letošních vydáních časopisu Chip. V tomto čísle se zaměříme na několik dílčích vylepšení, která připadla zajímavá mně, autorovi. Celkový stručný přehled o novinkách by mohl stále ještě být k nalezení na adrese [1], a pokud máte již novou verzi nainstalovanou, stačí vyvolat nápovědu What's New in Visual FoxPro 7.0. Rushmore po 10 letech Velké změny jsou ve Visual FoxPro 7.0 ukryty spíše pod povrchem a mají strategický rozměr (v domácích poměrech jsou motivací především pro naše "hodně budoucí" aplikace). Při bližším zkoumání mne samotného překvapilo postupné objevování detailů. To mne nakonec přivedlo k závěru, že přechod z dřívějších verzí Visual FoxPro do 7.0 nepochybně stojí za to. Drobné vylepšení funkce SYS(3054) mě kupříkladu vrátilo ve vzpomínkách do roku 1991, kdy za firmu Fox Software její ředitel evropského zastoupení Mark Daeche předváděl při svém turné po střední Evropě, co umí tehdejší žhavá novinka - FoxPro 2.0. Pamětníci si možná ještě vybaví tu kouzelnou ukázku: adresář firem s jedním milionem řádků a FoxPro má vyhledat stovku řádků vyhovujících zadané podmínce. Doba odezvy: neměřitelná, tedy zlomky sekundy. S úžasem padaly otázky: "Co to máte za počítač?" Odpověď zněla: "To je 'obyčejné' AT se 4 MB operační paměti." Aha, tedy ne tak úplně obyčejné, říkali si naši foxovští posluchači ještě plni dojmu z olomouckého semináře, kde jim kolega Milan Kosina vysvětloval, jak využít dalších 112 KB paměti v oblasti mezi 640 KB a 1 MB na svém XT. V předvedené ukázce nebyl žádný trik, šlo jen o dokonalé využití indexové technologie skryté do magického pojmu rushmore. Právě tato zkušenost se pro mnohé z programátorů stala etalonem pro vyhodnocování optimálnosti operací při přístupu k datům ve foxovských aplikacích. Rushmore se totiž uplatní jen tehdy, když se existující index využije "naplno". Potíž spočívá v tom, že neexistoval nástroj, který by způsob využívání indexu oznámil. Mnozí se tedy řídili vzpomínkou na zmíněnou ukázku: "milion vět = výběr musí trvat skoro nic"; trvá-li to několik sekund, něco není v pořádku a je třeba ladit dále. Teprve ve verzi Visual FoxPro 5.0 se objevuje nová funkce SYS(3054) (nejspíš bychom si její význam lépe zapamatovali, kdyby místo ní existoval příkaz SET OPTIMIZETALK ON/OFF). Že o ní jako foxař slyšíte poprvé? To je i má zkušenost z většiny kontaktů s domácími programátory. Co tedy SYS(3054) umí? Působí jako přepínač pro zobrazování hlášení o tom, jak se při výběrových operacích příkazu SELECT-SQL uplatňuje rushmore - tedy zda jsou optimálně využity indexy. Je-li zobrazování aktivováno - SYS(3054, 1) - a po vyvolání příkazu SELECT se jako součást hlášení zobrazí slůvko "full", znamená to, že využití indexů je optimální. Pokud jste v dosud popsaném neobjevili nic nového, zláká vás možná právě to, co je nové ve Visual FoxPro 7.0. Nyní totiž SYS(3054) umí zobrazit i příslušný příkaz SELECT (což je při ladění programů, které se hemží příkazy SELECT volanými za sebou, velmi užitečná maličkost). Zařídí to hodnota "2" ve druhém parametru funkce SYS. Navíc lze výstup přesměrovat z obrazovky do proměnné, takže dostáváme větší volnost v tom, jak s odhalenými výsledky naložit. Příklad: SYS(3054, 2, 'mVypis') ? mVypis Zobrazí se např.: SELECT * FROM BigOne WHERE F2 = "9X" Using index tag Tag2 to rushmore optimize table bigone Rushmore optimization level for table bigone: full Při testování této nové vlastnosti funkce SYS(3054) jsem po letech řešil otázku, jak velká musí být tabulka pro testování. Nejprve jsem si chtěl jenom stáhnout existující tabulku s 500 000 řádky na domácí počítač. Táhnout 50 nebo 70 MB po telefonu mi však nepřipadlo rozumné, a tak jsem si napsal generátor stejně, jako to dělá každý foxař, protože ví, že včetně naplnění tabulky to nezabere více než pár minut (a jako to stěží udělá ten, kdo používá SQL Server, VB či PowerBuilder, protože ví, že by tím ztratil spoustu času): CREATE TABLE BigOne (F1 C(20), F2 C(5), F3 C(40), F4 N(10)) m.NumOfCycles = 100000 FOR ii = 1 TO m.NumOfCycles m.F1 = SYS(2015) m.F2 = SUBS(m.F1,6) m.F3 = SYS(3)+m.F1+m.F1 m.F4 = RAND()*10000000 INSERT INTO BigOne (F1, F2, F3, F4) VALUES (m.F1, m.F2, m.F3, m.F4) ENDFOR Oněch 100 000 pokusných řádků (hodnota proměnné m.NumOfCycles) na mém podprůměrném 166MHz/64MB RAM bohužel dávalo neměřitelné odezvy, a tak musel generátor vytvořit 1 000 000 řádků. Pak už nějaké milisekundy bylo možné změřit. Kdy jste naposledy slyšeli, že FoxPro není prostředek vhodný pro práci s velkým objemem dat? A co to vlastně je "velký objem dat"? Když potřeboval testovací data k otestování výkonu FoxPro pod různými operačními systémy pro sérii svých článků Malcolm Rubel (v USA uznávaný autor textů a přednášek o FoxPro), nastavil toto měřítko: do 500 000 řádků jde o malou tabulku (číselník), do 1 000 000 jde o tabulku střední a 10 000 000 řádků je možné považovat za tabulku velkou. Zároveň dospěl k závěru, že i s "velkými" tabulkami lze ve Visual FoxPro pracovat a odezvy jsou přijatelné. Pro úplnost: SYS(3054) funguje jen pro příkazy SELECT (nikoliv tedy např. LOCATE FOR apod.) a vstupním parametrem lze rozlišit, zda chceme uplatnit zobrazování jen pro filtrovací podmínku (WHERE) nebo i pro vazební podmínku (která se uplatní při vázání několika tabulek pomocí WHERE nebo JOIN). Práce s poli paměťových proměnných Funkce pro operace s poli paměťových proměnných byly vždy silnou zbraní FoxPro. Čím více si na ně programátoři zvykli, tím intenzivnější byla jejich přání "Kéž by nějaká funkce uměla také ...". Právě do této kategorie patří novinky, které mohou zredukovat dosavadní programy o desítky kilobajtů. Pokud často používáte dvojrozměrná pole, nejspíš jste někdy potřebovali zjistit, na kterém řádku pole je zadaná hodnota. V horším případě se taková potřeba řeší kopírováním příslušné části kódu odjinud, v lepším si programátoři napsali "rozšířenou" funkci ASCAN. Funkce ASCAN ve verzi 7.0 konečně prohledává i po sloupcích a umí vrátit nejen pořadové číslo prvku, ale rovnou také číslo řádku. Příklad: Pole paměťových proměnných aPole má tento obsah: Dosud jsme byli zvyklí hledat hodnotu "X" ve 2. sloupci (prvek [4,2]) pomocí ASCAN asi takto: ? ASCAN(aPole, 'X') && vrací hodnotu 6 Z vrácené hodnoty 6 (X na 2. řádku ve 3. sloupci) jsme pak číslo řádku a sloupce mohli získat funkcí ASUBSCRIPT a zjistili jsme, že o tento sloupec nemáme zájem a že prohledávání musí pokračovat. Algoritmus pro prohledávání sloupců je tedy složitější. Visual FoxPro 7.0 rozšiřuje ASCAN o nový, pátý parametr, v němž lze zadat číslo prohledávaného sloupce: ? ASCAN(aPole, 'X', 1, -1, 2) && vrací správně hodnotu 11 Vrácená hodnota 11 nám ale neřekne rovnou, na kterém řádku nalezená hodnota X leží. Nová funkce ASCAN to umí prostřednictvím dalšího nového, šestého parametru: ? ASCAN(aPole, 'X', 1, -1, 2, 8) && vrací hodnotu 4 (4. řádek) Záhadná "osmička" v parametru souvisí s tím, že tento parametr se zadává prostřednictvím příznakových bitů a parametrem lze ovlivňovat i další chování funkce ASCAN, např. zda se mají rozlišovat při prohledávání textů malá a velká písmena. Význam jednotlivých bitů ukazuje následující tabulka: Kdybychom při volání ASCAN v předchozím příkladu zadali malé 'x' namísto velkého 'X', ASCAN je nenajde: ? ASCAN(aPole, 'x', 1, -1, 2, 8) && vrací hodnotu 0 (nenalezeno) Chceme-li tedy vracet číslo řádku a při vyhledávání nerozlišovat malá a velká písmena, použijeme: ? ASCAN(aPole, 'x', 1, -1, 2, 9) && vrací hodnotu 4 (4. řádek) Tentokrát "devítka" znamená, že bit 0 má být zapnut (hodnota 1) a také bit 3 má být zapnut (hodnota 8), což v součtu dává 9. Funkce může vrátit nejen hodnotu, ale i pole Jeden z evergreenů mezi požadavky na rozšíření funkčnosti Visual FoxPro zní takto: "Potřebuji, aby funkce (metoda) vracela několik hodnot, a ne jen jednu hodnotu. Nejlepší by bylo, kdyby uměla vrátit celé pole." Volání bylo vyslyšeno. Není to ovšem zcela hladké. Dejme tomu, že existuje funkce, která pracuje s trojprvkovým polem, jehož obsah má vracet příkaz RETURN. FUNCTION RetArray LOCAL ARRAY aPole [3] aPole [1] = "Jedna" aPole [2] = "Dvě" aPole [3] = "Tři" RETURN @aPole Následující pokus nám neprojde: x = RetArray() V souladu s trendem, že Visual FoxPro je moderní objektový vývojový nástroj, se předpokládá, že více pracujeme s objekty a méně v tradičním procedurálním kódu, jakým je uvedená ukázka. Aby funkce mohla vracet pole, musí platit, že pole (aPole) existuje i v době, kdy funkce (RetArray) je již ukončena. Tohle se dá splnit, když aPole bude vlastností (Property) objektu a funkce RetArray bude metodou tohoto objektu. Vracet pole je tedy možné, použijeme-li postup z této ukázky: Založíme program s názvem RetA.PRG: * RetA.prg DEFINE CLASS Test AS Custom DIMENSION aPole[3] PROCEDURE Init THIS.aPole[1] = "Jedna" THIS.aPole[2] = "Dvě" THIS.aPole[3] = "Tři" ENDPROC FUNCTION RetArray RETURN @THIS.aPole ENDFUNC ENDDEFINE Z nově vytvořeného objektu oTest můžeme pole nechat vrátit do nového pole ax (pokud neexistuje, založí se; pokud existuje, jeho počet prvků se přizpůsobí vracenému poli): oTest = NEWOBJECT("Test","RetA.prg") ax = oTest.RetArray() Maličkost pro pionýry v lesích klient/server Visual FoxPro už několik let dobře slouží v roli klienta v aplikacích, kde data jsou na nejrůznějších databázových serverech, jakými jsou např. Microsoft SQL Server, Oracle či Informix. Není to jen světová záležitost - existuje řada domácích řešení, která jsou založena na komunikaci Visual FoxPro s databázovými servery. Jedním z důvodů, proč data uložit ze souborů DBF někam jinam, bývá požadavek na zabezpečení dat před neoprávněnými přístupy. Visual FoxPro umožňuje dvě metody, jak se k datům připojit: jedna je založena na přímém odesílání příkazů SQL z FoxPro databázovému serveru (SQL Pass-Through, neboli SPT), druhá používá tzv. vzdálené pohledy, s nimiž se ve Visual FoxPro pracuje podobně jako s tabulkami DBF (pohled se např. otevře stejně jako DBF příkazem USE ). Obě metody vyžadují, aby byl přístup k datům podmíněn ověřením přihlašovacích údajů uživatele. Zde se uvedené metody liší v tom, jak jsou bezpečné: pro SPT stačí přihlašovací údaje držet pouze v operační paměti (po převzetí údajů od uživatele z přihlašovacího dialogu není potřeba je ukládat na disk). U vzdálených pohledů je to složitější: buď musí být přihlašovací údaje alespoň na okamžik uloženy v souboru (což samozřejmě znamená výrazné snížení bezpečnosti), nebo si přihlašovací údaje vyžádá každé otevírání pohledu příkazem USE. Visual FoxPro 7.0 obsahuje nové rozšíření příkazu USE - frázi CONNSTRING, ve které je možné přihlašovací údaje zadat přímo (nemusejí se tedy přebírat z jiného místa, kde jsou uloženy). Pro otevírání vzdálených pohledů lze použít nyní tento způsob se zadáním přihlašovacích údajů: USE CONNSTRING 'Driver=SQL Server;Server=(local);DataBase=Test;UID=PokusnýKrálík;PWD=KrálíkovoHeslo' Parametr pro frázi CONNSTRING se zadává stejně jako u příkazu SQLSTRINGCONN, který se objevil již ve Visual FoxPro 3.0. Závěr Visual FoxPro 7.0 rozhodně má co nabídnout. Koneckonců měl vývojový tým v Redmondu na přípravu dostatek času - téměř dva roky. Verzi 6.0 používáme totiž už od poloviny roku 1999. V této souvislosti je pochopitelné, že čekání na Visual Studio.NET s téměř hotovou verzí Visual FoxPro 7.0 by bylo svým způsobem zbytečné. Navíc v době, kdy se objevily první náznaky toho, co má obsahovat verze příští. Že by 8.0? Možná i o tom se dozvíme více v červnu na konferenci Visual FoxPro DevCon, Praha 2001. Igor Vít Použité odkazy: [1] http://msdn.microsoft.com/vfoxpro/prodinfo/vfp7.asp [2] http://www.daquas.cz/fox/devcon2001