58
A VisualFoxpro adatbázisfejlesztő rendszer
-
#1
Na most már nyitok ennek a témának egy topikot, mivel az EGÉSZ nagy Magyarországon nem találok hozzá sem magyar nyelvű könyvet, sem doksit, sem semmilyen leírást. (Egyetlen helyen találtam egy 3.0-ás verzióhoz könyvet, holott már a 8.0 a naprakész)
Teljes elkeseredésemben remélem, hogy rajtam kívül is meg akarja ismerni ezt a rendszert. -
#2
Ha ez a teljes hivatalos neve, hogy Visual FoxPro, akkor nincs nekem sem, pedig elég sok "E-Bookom" van. -
#3
Microsoft Visual FoxPro vagy csak simán foxpro, bár elvileg a 3.0 óta a Visual családba tartozik... -
BlackHawks #4 Sziasztok!
Itt van a kezemben 1 könyv:
Nádai - Rezessy : Visual Foxpro 6.0 2680Ft
ha elakadok, akkor itt találok útmutatást
Tényleg elég mostoha a magyar könyvanyag, szégyen, pedig szerintem egész jó kis adatbáziskezelő progik készíthetőek vele
Bye! -
#5
Kérdezz, és ha tudok, felelek. Öt éve nyomom a FoxPro-t, a DOS-os 2.6-tól kezdve a legújabb 8.01-ig. :)
Magyar doksit én sem tudok a lentebb említett könyvön kívül, de angol nyelven az MSDN-en kívül is elég sok létezik belőle.
-
#6
na az a könyv kifutott, viszont találtam egy foxpro 5.0*6.0 könyvet Gacsó Zoltán nevével fémjelezve. Ezt most tanulmányozom.
PetruZ: Kössz a felajánlást, azthiszem élni fogok vele... -
#7
De csak ha itt kérdezel. A levelezést hanyagoljuk, ismeretlen címről le sem töltöm a levelet, rögtön törlöm, a rengeteg spam miatt. :)
-
#9
egyértelmű, nem mailozok
bu-bu: először csak win9x alatt, az SQLServert egyelőre hanyagolom, de azé' kössz -
#11
kézzel, ahhoz szoktam eddig
egyenlőre a függvényekkel barátkozom...
egyébként ez inkább a dbase-hez hasonlít, vagy inkább egyedileg beépített?
.......
érdekes, a visual studio tagja révén furcsa, hogy a nyelv sem a c++-hez, sem a visualbasic-hez nem hasonlít, nem? -
#13
azt nem értem,(legalábbis amit olvastam róla), miért implicit módon szereplenek a változók? -
#14
Mire gondolsz pontosan?
Egyébként a VFP már nem tagja a VS családnak (a 6.0 volt az utolsó, ami a VS-ben jelent meg).
-
#15
arra, hogy a változókat nem kell deklarálni?
olvastam egy szar könyvet a foxpro-ról, és abban a szaki úgy írta az eljárásokat, hogy a kódrészben megnevezett egy változót, majd annak értéket adott, oszt kész. Később ebből a változóból hívott értéket.
Sajnos nem tudok példálózni, mert nincs nálam a könyv. -
#16
egyébként igazad van, csak a 6-osig volt a visual része, bár én is 6.0 -al "botladozom" éppen.
sajna nics többszázezrem a 8.0-ásra -
#17
Hát... elvileg nem kell. De lehet, illetve public változóknál kell is. Egyébként ez a változósdi elég kavarós a FVP-ben, mivel a form objektumok nem látják a külső eljárásokon kívüli változókat (csak a public-ként deklaráltakat), de ha pl. egy form metódusból hívsz egy külső függvényt, akkor a megegyező változónevek bizony azonos adatterületre fognak hivatkozni (hacsak nincsenek külön local-ként deklarálva).
Pl.:
(ez külön prg blokkban, más fájlban)
procedure kulso_eljaras(y)
x=y*10
return
A metódusban meg ez van:
...
x=3
kulso_eljaras(x)
...
Az eredmény? A várakozásoknak "megfelelően" az "x" értéke 30-ra fog változni... Elég könnyű beleesni ebbe a csapdába, célszerű inkább a külső eljárásokon, függvényeken belül a "local" használata.
Sajnos a VFP ezen nagyvonalú lazasága elég bosszantó tud lenni néha, pláne ha azt nézzük, hogy ehhez képest az automatikus konverziók sokszor pont úgy működnek, ahogy nekünk éppen nem kell. Különösen a form mezőknél szokott előjönni ez, ha feldolgozod az értéküket és csak futásidőben (azok a kib* "type mismatch" üzenetek :] ).
Én elsősorban azért használom a VFP-t, mert a fejlesztéseimben többnyire nagy adathalmazokból, több adatbázisból (Oracle) SQL-lel lehúzott kurzorokkal kell dolgozni, és nagyon jól és gyorsan lehet mókolni, átalakítgatni és összekapcsolni őket. A form kezelői részét és a vezérlőelemeit viszont nagyon gyatrának érzem, az "igazzy" OOP-től majdhogynem idegennek. Arra viszont nincs idő, hogy kézzel programozzam le az egészet. :)
-
#18
Hát ez az! Pont ez a probléma bosszant engem is! Ráadásul még ki sem lehet kapcsolni, illetve kötelezővé tenni a deklarálást.
Nem értem, ha azt akarom, hogy az 'x' eljárásban szereplő 'z' változóm értékét 'y' eljárásból le tudjam kérni, ahhoz az 'x' eljárást public-ként kell jelölni?
Nem lett volna egyszerűbb, ha a 'z' változómat public-ként deklarálom?
Egyébként BUÉK! -
#19
Valamit keversz: ami leírsz, azt elvileg nem is szabad megengedni és szerencsére nem is működik. Akkor lenne még csak nagy balhé, ha az egy modulban szereplő eljárások látnák egymás változóit. Eljárás public-ként való deklarálásának nincs is értelme, viszont a(z osztály) metódus és az eljárás/függvény a VFP-ben (is) eltér, nem ugyanaz a működési mechanizmus!
-
#20
Amint látod, még csak kóstolgatom ezt a dbase elvet...
Arra akartam kijukadni, hogy egy modulon belüli eljárások EGY változót használjanak egy bizonyos adat kezeléséhez. Pl az egyik eljárás feltölti, míg a másik lekérdezi stb. Vagy egy boolean változó értékét több eljárás is figyelhesse ecc.
-
#21
Ha ilyet akarsz, azokat a változókat az eljárásokon kívül, a modul fejlécében public-ként kell deklarálni.
-
#22
Lenne agy kapcsolatos kérdésem, egy labdarúgás hasonlattal élnék, hátha így könnyebben értelmezhető:
Egy fordulóban több mérkőzés is lehet, de minden csapat csak egyszer játszhat(mérkőzéseredmények tábla). Egy fordulóban egy csapat több játékosának rögzíthető a teljesítménye (gól, gólpassz stb.), de mindegyiknek csak egyszer(játékosstatisztika tábla).
A mérkőzéseredmények és a játékosstatisztikák egy-egy külön táblában vannak tárolva. Ennek a rendszernek a kapcsolatait kellene úgy megoldanom, hogy az említett "törvények" teljesüljenek, és az adatok könnyen lekérdezhetők legyenek.
Várom a megoldásokat! -
#23
Hát, én mondjuk elsőre azt csinálnám, hogy az eredménytáblába elhelyeznék egy egyedi kulcsot (mondjuk egy folytonosan növekvő szám is jó; unique key index, ha így ismerősebb). A statisztika táblának ez idegen kulcsa (foreign key) lenne, az eredmény - statisztika között 1:N kapcsolattal. A statisztika táblán ez a mérkőzésazonosító plusz a játékos azonosító szintén külön egyedi kulcsot alkotna.
Így az egyediséget minden esetben le lehet fedni, az adatok összekapcsolása pedig a mérközésazonosító alapján egyértelmű (egy mérkőzéshez több stat sor tartozhat, de mindegyiknek csak egy játékos sora lehet a második unique key miatt). A korlátokról maga az adatbázis gondoskodik a két unique megszorítás miatt.
Pl. (csak nagyon vázlatosan, a konkrét táblastruktúra ismeretében tovább finomítható, csiszolható):
-egy játékos adatai egy adott mérkőzésen: select a.*, b.* from merkozes a, stat b where a.merkozes_id = b.merkozes_id and b.jatekos_id = XXX and a.merkozes_id = YYY;
-egy játékos mely mérkőzéseken játszott: select a.* from merkozes a, stat b where a.merkozes_id = b.merkozes_id and b.jatekos_id = XXX;
És így tovább. A lényeg a két tábla összekapcsolása a merkozes_id alapján, a többi már gyerekjáték.
-
#24
Még valami: ha szükséges, hogy az egyes fordulókban egy csapat csak egyszer szerepelhessen, akkor a legegyszerűbb megoldás, ha a mérkőzés táblában az egyedi mérkőzésazonosító megmarad, de ezen felül a forduló sorszámából, a mérkőzésazonosítóból és a két csapat azonosítójából egy újabb egyedi kulcsot kell képezni (a forduló dátuma nem jó, mert egy forduló több napon át is tarthat és halasztás is lehet). Ezek összekapcsolása a statisztika táblával *nem* szükséges (nincs is mivel), csak az egyediséget garantálja. Az egyes adatokat a csapatok adattábláival lehet összekapcsolgatni.
-
#25
Kitűnő!
...játékos azonosító szintén külön egyedi kulcsot alkotna.
1-N kapcsolattal a [játékosnevek] tábla azonosító kulcsához? -
#26
Nem pontosan, bár arra is használható (csak fordítva): ahogy írtam, a mérkőzés azonosító plusz a játékosazonosító alkotna még egy új egyedi kulcsot a statisztika táblán (ez garantálja, hogy egy játékos egy mérkőzésen csak egy statisztikai sorral rendelkezzen). A játékosnevek táblán a játékos azonosító természetesen önmagában egyedi kulcs és az kapcsolódik 1:N-el a statisztika táblához.
-
#27
Hali all...
Ha vkinek van VFP5-os futtato kornyezet (kb 3 dll), plz linkelje mar be, vagy irjon, ha at tudna kuldeni...
koszi... -
#28
Koszi, mar talaltam... -
nippy #29 Valaki próbált már egy létező EXCEL file-ba adatokat irni ?
Ha igen érdekelne
Új excel file-t gond nélkül lehet készíteni.
Esetleg valakinek ötlete ? -
#30
Ja, pár éve kellett, akkor OLE-n keresztül csináltam - de baromi lassú.
Pl.:
...
if type( 'GETOBJECT(, "Excel.Application")' ) = "O"
OLEExcel=GETOBJECT(, "Excel.Application")
else
OLEExcel=CreateObject("Excel.Application")
endif
with OLEExcel
.Visible=.t.
.workbooks.open(fájlnév, 0, .f.)
.sheets(1).select
...
Innentől kezdve elméletileg a teljes VBA scripting funkcionalitás a rendelkezésedre áll, csak ne feledkezz meg az előpontokról, hogy az OLEExcel objektumon keresztül dolgozzon. A FoxPro-t nem érdekli, hogy a számára többnyire értelmetlen dolgok lehetnek itt, ő szépen továbbpasszolja majd az Excelnek.
...
release OLEExcel
...
Megismétlem: ez egy nagyon lassú módszer...
-
nippy #31 Már a GETOBJECT -re hibát jelez ,hogy "OLE hiba :a művelet nem hajtható végre"
Kicsit tanácstalan vagyok..
-
#32
Excel van telepítve a gépre, ahol próbálod? Nálam pár éve 7-es és 8-as FoxPro-val működött Excel 95-től 2000-ig. Már nem Fox-ozok, a részlet egy régi alkalmazásom forrásából van, amit széles körben használt a volt cégem, gond nélkül.
A gépemen van egy Fox8-as, most kipróbáltam rajta, de nekem működik. Igaz, nincs Office a gépemen, de nem a GetObject(()-tel van baja, hanem az else ággal, ugyanis nem tud Excel objektumot kreálni (ahogy az logikus is).
Ennyi volt az egész program:
if type( 'GETOBJECT(, "Excel.Application")' ) = "O"
OLEExcel=GETOBJECT(, "Excel.Application")
else
OLEExcel=CreateObject("Excel.Application")
endif
with OLEExcel
.Visible=.t.
endwith
release OLEExcel
Compile lement, futtatás is megy. Sztem valamit kihagytál / elgépeltél (idézőjelek, vesszők nem mindegy, hol vannak).
-
nippy #33 Lehet hogy az excel 2003 -mal van a hiba ?
7-es FoxPro-val próbáltam
Meg fogom nézni egy másik gépen ahol 97-es office van.
-
#34
Nem hinném, az MSDN library szerint is ezt, ilyen formában érdemes használni, nincs megkülönböztetés. Bár előfordulhat, hogy a hivatkozás hibás / hiányos. :)
-
nippy #35 Van arra külön parancs, ha feldolgozottságot szeretnék megjelentettni, ugyan úgy mint amikor megy egy install és %-osan húzza a csikot ?
-
#36
Nincs, neked kell megírni, vagy használhatsz vmi külső (jellemzően OCX v. ActiveX) komponenst. Ez már kicsit túlmutat az alap FoxPro programozáson.
-
nippy #37 Használtál már activeX-et ? Mert én még nem, ha egy kis iránymutatót adnál, nagyon megköszönném.
-
#38
Pl. nyiss egy új Form-ot, a toolbar-ról dobj rá egy ActiveX Control (OLEControl) objektumot. A megnyíló listában keresd meg pl. a Microsoft ProgressBar Control 6.0-át, majd méretezd kedved szerint. Bizonyos paramétereit beállíthatod kézzel, ha jobbklikket nyomsz rá, majd a menüben a ProgCtrl Properties pontot választod. Ugyanezek a property-k (és a többi is, ami nincs itt), programozás oldaláról is elérhető (pl. az olecontrol1.value kell neked a pozíció beállításához). A pontos leírásokat az MSDN Library-ből tudod előásni.
-
nippy #39 Köszi ! -
nippy #40 Most már csak az érdekelne, hogy hogyan foglalod keretbe a folyamatot ?
pl.
olecontrol1.value=0,0001 & az induló érték
de hogy fog automatikusan dolgozni ?
-
#41
Mit jelent az, hogy automatikusan? Mit kell dolgoznia? Sejtem, mire gondolsz, de vajon tudod-e, hogy mire gondolsz, és mit akarsz megvalósítani? :) Biztosan automatikusan kellene mennie?
Az ilyesféle event kezelés kicsit tág témakör, úgy nagyjából a modern programozás háromnegyedét valamilyen szinten érinti...
-
nippy #42 Én azért egyszerübb dologra gondoltam :)
Pl.
van egy nagy adatbázis (néha 100000 record feletti)
ezt indexelni, ebből leválogatni sql-es parancsokkal is időígényes
ezt szeretném látni, hogy épp hol tart.
(az automatikus csak a csík megjelenítése lenne)
-
#43
A százezer rekord az nudli, a nagy adatbázis úgy tízmilliós nagyságrendnél kezdődik. :)
De egyébként ezt nem tudod megcsinálni FoxPro-ban (automatikusra), csak akkor, ha te programozod a keresést. Nem tudom, milyen típusú adatbázisról van szó, de a legtöbb nem fogja neked a belső működését megmutatni (nem fogja megmondani, hol tart az indexelésben, vagy a sorok leválogatásában, mert ez nem ilyen egzakt dolog; az adatbázisok belső működése majdhogynem külön tudomány :) ), csak azt tudod számolni, hogy a lekérdezés végén hány sor jött, és a sorok át-fetch-elése hol tart. Ha ezt meg akarod jeleníteni, az programozott dolog, nincs rá automatika. Ez esetben neked kell pl. a progressbar-t vezérelni.