Relationsdatabas
Jag tror det är bra om du bekantar dig med själva grundidén för en relationsdatabas. En Layout i FileMaker är, något förenklat, ett sätt att visa data på, men innan du funderar på det måste du fundera på hur data ska hänga ihop – dvs. vilka relationer som ska finnas.
Tabeller
Data lagras i tabeller. Det finns ingen allmängiltig regel för vilka tabeller som bör finnas, men i princip så handlar det om kategorisering, dvs. vilka "slag" som du behöver hålla reda på.
Ditt exempel tycker jag som minimum bör använda två tabeller, en för Offerten som sådan, och en för de "offertrader" som offerten kan inkludera:
Tabellernas fält
Tabellen "Offert" innehåller det numeriska fältet "OffertID" och textfältet "OffertNamn" och dessutom beräkningsfältet "Summa" (som du ska återkomma till lite senare)
Tabellen "OffertRader" innehåller också ett numeriskt fält som vi för enkelhetens skull kallar "OffertID" och textfältet "Produktnamn" och det numeriska fältet "Pris"
Layout
Varje tabell du skapar får automatiskt en layout, som i grunden visar den egna tabellens fält
Relationen
För att nu koppla ihop dessa två tabeller anger du att det ska finnas en relation mellan Offert:OffertID och OffertRader:OffertID, där poster som har samma värden (ett nummer) ska höra ihop.
Visa relaterade poster på en layout med hjälp av en portal
För att nu visa detta så kan du på den första layouten "Offert" inkludera en portal, som visar poster från den relation du just skapat, och lägga dit fälten OffertID (lite överflödigt i just detta fall, men bara för principens skull) och Produktnamnet
Summa-fältet
I tabellen "Offert" och dess fält summa ska du nu ange att du vill att den ska använda funktionen
Värdelistor
Värdelistor, fältkontroller etc. har i det här fallet mest funktionen av att underlätta inmatning och se till at du får de texter respektive siffror du har tänkt, men de avgör egentligen inte funktionen
Den här typen av enkla uppsättningar funkar bra många gånger, andra gånger så utvecklar man det lite mer och har en särskild tabell som håller reda på relationen, det har bl.a. vitsen att det blir lätt att hålla ett särskilt produktregister, där varje produkt finns bara en gång, varje offert bara en gång, men kopplingen sker varje gång man offererar en sådan produkt till någon. På så viss slipper man upprepa en massa data. Men som sagt, för enkla saker är det ofta overkill
