Hogy mások ne bukjanak el ezeken… És mert a FileMaker kellő önfegyelem mellett jó fegyver. 
Ha az ember text típusú mezőt választ kulcsmezőnek, akkor érdemes figyelmet fordítani a mező indexelésnek nyelvére is, mert az indexelés nem veszi figyelembe az ékezeteket, ami vagy épp az, amit szeretnénk vagy épp nem. Ha unicode-ra állítottam volna a foreign key indexelésének nyelvét, akkor nem lennének kapcsolódó rekordok a portálon. (FileMaker 3-óta így működik és nem nagyon van emlegetve ez a tény.)
A dolog valahol ott kezdődik, hogy key fieldnek, akár primary, akár foreign, nem tanácsos csak az angol abc karaktereit és számokat használni. Már csak azért is, mert a key fieldek jellemzően auto-enter fieldek. Szóval aki ÁÉŐŰ-t ad meg key fieldnek egy szimpla CUS001 helyett, az “megérdemli”… Amúgy jogos az észrevétel! ;-)
A filemakeres topicnak nagyon örülök, hátha többen is megismerik, mert bazi jó cucc! ;-)
Mi csak id-vel kapcsolunk ossze tablakat.
Egy Mac-es fórumon nem lehet, hogy ne legyen egy FileMaker topic. ;-)
Az én esetemben nem volt választás. A feladat a számlázónk kiegészítése volt újabb képességekkel és számlázó szoftverben a készítők lehetővé tették, hogy bármilyen alfanumerikus karakter lehessen termékkód, mondhatni egy “natural key”. Így a nem mindig tapasztal felhasználók a lehető legváltozatosabb termékkódokat hozták létre az elmúlt 10 évben. :-) Akár még egy vagy több szóközre is végződhet egy termékkód.
De a termekeknek nincs egy autoincrementes id-ja, amit a felhasznalo esetleg nem is lat???
Van, de minden reláció a termékkód alapján működik. :-)
Ezt talan erdemes lenne atalakitani… :)
Gratulálok a számlázóprogram készítőinek! :-)
Esőjáróval maximálisan egyet értek, én is átalakítanám az egészet! A termékkód mellé betennék egy id-t amitől a termékkód még maradhat unique value.
Ebből így előbb-vagy utóbb csak nagyon nagy baj lesz…
Ark azt mondja, hogy van id, csak nem azt hasznaljak. A kapcsolodo tablakban kellene relaciot letrehozni a termek_id-vel.
Vissza a FileMakerhez! Nem volt célom a számlázónkat porba alázni. ;-)
Ez a szakmai tanacsunk, nem alazas. :D Ha hozzafersz a szamlazo forrasahoz, alakitsd at a kapcsolatokat. Es akkor nem kell szivnod a stringes kulccsal.
A forráshoz nem, csak ODBC-n tudok kinyerni belőle adatokat.
(A világ megbotránkozására: A számlázó 4D-bek készült és csak a következő verzió fogja elérni azt, hogy minden részében relációs alapokra épüljön. Eddig részben a FileMaker repeating fieldjének 4D-s megfelelőjére támaszkodott.)
Nem is mondok semmit.
De ha 4D-s szamlazo, akkor az a CIPO. :D
A működőképesség és a minőség nem függ össze. A CIPO működik, nincs benne több bug, mint más szoftverben. Szerintem még mindig jobb, mint a konkurenciája.
Persze. Attol, hogy mukodik, meg lehet horror, es attol, hogy horror, meg mukodhet. :)
Olvasgatom a FileMaker Pro 13: The Missing Manualt és lábjegyzetként megjelenik az egyik oldalon, hogy timestamp mezőnél a mező egyedi formázása csak akkor “aktiválódik”, ha a dátum és az idő formázásán is állított az ember. Pár hete emiatt vakargattam a fejem egy ideig, mire rájöttem. :-)
http://www.amazon.co.uk/FileMaker-Pro-13-Missing-Manuals/dp/1491900792/
Elolvastam ezt a könyvet és nem találtam valami jónak. Ha egy mondatban össze akarnám foglalni:
Ha valaki elolvassa ezt a könyvet, akkor tisztában lesz a FileMaker képességeivel, de ettől nem lesz jó FileMaker “programozó”. Nem figyelmeztet és nem ad jó példákat ott, ahol leginkább el lehet bukni a FileMakerben. (a relációs modell minimális ismerete, tabe occurances elrendezése, használható nevezéktan kialakítása, hogy az ember ne bolonduljon meg.)
De gyakorlatilag nem maradt más a piacon a FileMaker saját Training Series-én túl, sajnos.
A Wiley FileMaker Pro Bible-jeben vannak infok a relacios adatbazisokrol, mondjuk nem az elejen, hanem az otszazadik oldal magassagaban, de ha jol tudom, az utolso ilyen konyv a FileMaker 10-rol szol. De igen, igazad van, azzal kellene kezdeni, hogy egy tablaban csak egy fele dolog legyen, id-val kapcsolj ossze tobb dolgot, es tudd, mi az a kapcsolotabla a many-to-many relationshipshez. A lower_snake_case tabla- es oszlopnevek a legtutibbak, hacsak a leghalvanyabb esely is van, hogy egyszer az adatbazist at kell exportalni egy masik adatbazis appba. Aki ekezetet hasznal layouton kivul, azt meg kellene raznia a billentyuzetnek.
Őszintén merem Neked ajánlani a John Mark Osborne: FileMaker Pro 12 (Beginner, Intermediate, Advanced) videó tréning sorozatát. DB concept ebben sincsen kimondottan, viszont a gyakorlati dolgokat rendkívül érthetően adja át és nekem az előadóstílusa is nagyon bejön.
http://www.amazon.co.uk/Advanced-FileMaker-Techniques-Developers-Wordware/dp/1556228597/
Nekem ez volt az első és utolsó FileMakerről szóló könyv, amire azt mondtam rendben van. Deklaráltan nem kezdőknek íródott és ez jót is tett a könyvnek, mert fókuszálni tudott 2-3 érdekesebb témára. A FileMaker irodalomban ezen kívül nem láttam olyat, ahol megpróbálták volna leírni, pl. hogy hogyan működik és hogyan lehet megvalósítani egy “outer join”-t FileMakerben.
De a 7-es előtti FileMaker egy másik világ.
