Zero55 Geplaatst: 4 december 2007 Delen Geplaatst: 4 december 2007 beste allemaal, ik heb een fm5.5 database geconverteerd naar fm9, allemaal goed en wel gelukt. Maar nu wil ik de data scheiden van de layouts. Hoe moet dit in de praktijk ingesteld worden in fm dat het layoutbestand de data uit het databestand haalt ? groeten. Quote Link naar reactie
0 Glimmie Geplaatst: 4 december 2007 Delen Geplaatst: 4 december 2007 beste allemaal, ik heb een fm5.5 database geconverteerd naar fm9, allemaal goed en wel gelukt. Maar nu wil ik de data scheiden van de layouts. Hoe moet dit in de praktijk ingesteld worden in fm dat het layoutbestand de data uit het databestand haalt ? groeten. Ik ga er vanuit dat je 2 tabellen hebt gekoppeld. Dan kun je een samenvoegveld gebruiken of het veld uit de andere tabel invoegen. Een samenvoegveld ziet er als volgt uit: tabelnaam::veldnaam Dus tabelnaam dan 2 dubbelepunten en dan de veldnaam. Gr., Glimmie Quote Link naar reactie
0 Zero55 Geplaatst: 4 december 2007 Auteur Delen Geplaatst: 4 december 2007 bedoel je met gekoppeld een relatie tussen de 2 tabellen dmv een uniek veld (key) ? Ik heb nog geen relaties gelegd....heb enkel de datafile klaar... Quote Link naar reactie
0 Zero55 Geplaatst: 5 december 2007 Auteur Delen Geplaatst: 5 december 2007 Als ik data en layouts gescheiden wil houden, in welke file zitten dan de calculatievelden en de scripts e.d.? Omdat... momenteel zitten een heel aantal van die calculatievelden en scripts natuurlijk in mijn (uit fm5.5 geconverteerde) database file. Database (de data-file uiteindelijk) zie bijlage. Unit Details Oud.zip Quote Link naar reactie
0 Yves Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Ik houd de data strikt gescheiden van de rest : bij een update - we werken met dezelfde toepassing op meerdere plaatsen - moet je dan alleen je lay-out/scriptgedeelte installeren en dus geen data gaan importeren. Quote Link naar reactie
0 Zero55 Geplaatst: 5 december 2007 Auteur Delen Geplaatst: 5 december 2007 en in de data-file zitten dus geen berekeningsvelden of zo ? enkel "platte" data ? In ons geval zit in de datafile de gegevens over een unit, nl. klant, afmetingen, kleur, e.d.... er zijn ook velden die afhankelijk van de afmeting van de unit ingevuld/berekend moeten worden, mag dat in de data-file ? bvb als een unit korter dan 6m is, mogen er geen trekbaren in gelast worden, het veld trekbaren is dus "0". Quote Link naar reactie
0 Yves Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Trek de data uit die file in een nieuw bestand en behoud de berekeningen. Dan moet je weliswaar éénmalig je velden aanpassen. Quote Link naar reactie
0 Zero55 Geplaatst: 5 december 2007 Auteur Delen Geplaatst: 5 december 2007 dus een nieuw bestand aanmaken met nieuwe datavelden en de data uit het oude bestand importeren in het nieuwe. De data die is berekend geworden in het oude bestand als data invoegen in het nieuwe bestand (nieuwe velden) ? En in de toekomst doe ik dan mijn berekeningen in het layout/scriptgedeelte in de uitkomst plaats ik in het databestand ? Bedoel je zoiets ?? sorry, maar ik ben niet zo goed mee met uw redenering, ben nog maar een n00b in fm9 Quote Link naar reactie
0 Maarten Witberg Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Sorry voor de inbraak... ik heb me nog niet echt in de materie verdiept. Maar is echte dataseparatie wel mogelijk in filemaker? Ik probeer me voor te stellen waar ik een print layout voor lineitems zou neerzetten als de lineitems in de datafile zitten. En wat zit er dan aan records in de gebruikersinterface? ik neem aan een record per gebruiker / account. Ik snap het importeer / upgrade voordeel maar ik heb me er nog niet aan gewaagd, het is structureel toch wel effe wat. Of is het veel simpeler dan ik denk? Een datastructuur waarbij de hele interface via een gebruikerstabel gaat heb ik al wel gemaakt, maar toch met alles in 1 bestand. Benieuwd naar je reactie Quote Link naar reactie
0 Rony Rabijns Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Ik snap het importeer / upgrade voordeel maar ik heb me er nog niet aan gewaagd, het is structureel toch wel effe wat. Of is het veel simpeler dan ik denk? We hadden er op de laatste Confituursessie nog een boeiende discussie over. Ikzelf ben er "tegen", en schijnbaar had ik nogal wat medestanders. Wat me nog het meest in mijn overtuiging sterkt, is dat een aantal gerenommeerde ontwikkelaars er ook van teruggekomen zijn. Het is niet simpeler, het is veel meer programmeerwerk, je moet bvb heel veel navigatie scripten, veel zaken kan je niet oplossen, en qua updaten .... als de structuur verandert, ben je vaak verplicht zowel de data als de layouts aan te passen. Wat is je voordeel dan nog. Conclusie: Alles is relatief. Datascheiding kan. Kan je er je voordeel mee doen, wel, doe het dan indien de klant bereid is er voor te betalen, maar hou in gedachten dat FM er niet voor/op gemaakt is. Quote Link naar reactie
0 Maarten Witberg Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 hou in gedachten dat FM er niet voor/op gemaakt is Dank Rony. Ik laat het nog maar even links liggen. Je laatste opmerking bevestigt mijn vermoeden. Quote Link naar reactie
0 JeanWM Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Hangt ervan af vanuit welk standpunt je vertrekt. Indien je een gewone database toepassing neemt, daar de navigatie afzonderlijk zet en de data afzonderlijk zet en deze twee dan met mekaar laat praten, waarbij je alle functionaliteit wil behouden, zal het nooit lukken. Met haken en ogen en ducktape en een steriliseerbokaalelastiek zal wel iets lukken maar nooit alles. Je probeert een data model in een database model te wringen of omgekeerd. Indien je vertrekt van entity, attribute en node, en niet verder gaat, is er kans op slagen. Die zaken komen in een bestand dat genormaliseerd is. Je GUI steunt op het CQS principe en zit in een tweede bestand. Je zit dus niet op het niveau van database, maar op het niveau van data warehouse. En dat zijn twee totaal verschillende toepassingen die ieder hun eigen regels hebben. Ik heb verschillende toepassingen lopen steunend op het separation model, met een koppel 100.000+ records, die vanuit verschillende locaties tegelijkertijd kunnen bekeken worden en waarbij rapporten kunnen gegenereerd worden zonder enig probleem. De benadering hier is data warehouse en NIET data base. Akkoord, FileMaker kan niet alles, maar FileMaker kan véél… Quote Link naar reactie
0 Maarten Witberg Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 Als je datawarehouse definitie met deze overeenkomt: http://nl.wikipedia.org/wiki/Datawarehouse dus over niet operationele gegevens, dan is het niet echt iets voor gemiddelde toepassingen... nog meer wikipedia, om te kijken wat CQS is : http://en.wikipedia.org/wiki/Command-query_separation Helaas werd ik daar niet echt wijzer van. Het lijkt te gaan over programmeertalen en Filemaker is veel maar geen programmeertaal. Betrokken op de GUI zou ik denken dat je doelt op helder onderscheid tussen commandos (maak een print? ga naar X?) en queries (zoek alle data die voldoet aan Y) maar ik zie niet hoe dat me helpt tot een goed data separatie model te komen. Daar kunnen overigens meer redenen achter zitten. nog zo wat: http://en.wikipedia.org/wiki/Database_normalization met "entity attribute node" als zoekterm kwam ik niet verder. wikipedia heeft niet het laatste woord en vertrouw vooral geen info over bekende personen, maar je kan er wel veel vinden. hoop dat je betere bronnen voor me hebt want deze amateur zoekt kansen om gaten in de basiskennis te dichten. niet zozeer om daarna tot data separatie over te gaan trouwens Quote Link naar reactie
0 JeanWM Geplaatst: 5 december 2007 Delen Geplaatst: 5 december 2007 hoop dat je betere bronnen voor me hebt want deze amateur zoekt kansen om gaten in de basiskennis te dichten. niet zozeer om daarna tot data separatie over te gaan trouwens Wiki's geven misschien een hoop informatie maar niet altijd de juiste, dikwijls zelfs ronduit verkeerd. Je maakt de meeste kans door een cursus te volgen aan, voor jou, OpenUniversiteitNederland. Die hebben op dit ogenblik een zeer goede over database. CQS is geen programmeertaal, wel een manier van werken binnen databasestructuren. Advanced scripting doe je best volgens de CQS regels, in FileMaker. Vandaar mijn stelling bij FileMaker, begin met al te functies te leren. Iedere routine die je binnen FM gebruikt steunt op de toepassing van een functie. Entity, attribute,node is de basis voor iedere relationele database. Beheers je dat niet... Maar Ilyse Kazar zei het al; FileMaker is, in de eerste plaats, voor end-users.... Quote Link naar reactie
0 Maarten Witberg Geplaatst: 6 december 2007 Delen Geplaatst: 6 december 2007 CQS is geen programmeertaal nee, dat zei ik ook niet begin met al de functies te leren tja... toepassen is leren... Entity, attribute,node Het valt me op dat veel info die vrij verkrijgbaar is op internet -waaronder wiki artikelen over IT onderwerpen- niet uitblinkt door helderheid, of tegenstrijdig is aan iets dat je ergens anders vindt, of alleen geschreven lijkt voor de auteur zelf. Dan zit ik ermee dat het allemaal in het engels is en hoewel ik me daar aardig in red is engels jargon vaak ondoorgrondelijk. Kortom voor mij is 'toepassen is leren' nog steeds de bron. Ik heb toch wel wat werkende en ik dacht ook solide databases in elkaar gezet zonder sommige delen van de IT kretologie te doorgronden. Nochthans ga ik eens rondneuzen bij de OU, want ik vroeg niet voor niets om betere bronnen voor basiskennis. met veel dank voor de tip. Quote Link naar reactie
0 JeanWM Geplaatst: 6 december 2007 Delen Geplaatst: 6 december 2007 Ik heb toch wel wat werkende databases in elkaar gezet zonder sommige delen van de IT kretologie te doorgronden. ...waarschijnlijk enkel FileMaker toepassingen... Quote Link naar reactie
0 Maarten Witberg Geplaatst: 6 december 2007 Delen Geplaatst: 6 december 2007 yep. fijn programma. Quote Link naar reactie
0 JeanWM Geplaatst: 7 december 2007 Delen Geplaatst: 7 december 2007 Dan zijn het FileMaker toepassingen... Quote Link naar reactie
0 Maarten Witberg Geplaatst: 7 december 2007 Delen Geplaatst: 7 december 2007 waar gaat dit heen? met filemaker maak je toch databases? [/i] Quote Link naar reactie
0 peterS Geplaatst: 7 december 2007 Delen Geplaatst: 7 december 2007 Zero, Ik heb de afgelopen maanden, na lang twijfelen LabScores herschreven om het DataSeparationModel toe te passen. Veel werk, inderdaad en er blijven altijd calculaties die je in de data file moet houden maar, afhankelijk van de FM oplossing en je business model (in huis, commercieel etc) als het eenmaal gebeurd is is het wel erg makkelijk om upgrades te installeren. Twee grote voordelen op dat moment, de klant heeft nauwelijks meer downtime tijdens de upgrade en het kost als ontwikkelaar minder tijd om bij verschillende klanten de laatste versie te implementeren (hoewel FMS9 dat wel makkelijker maakt). De extra navigatie scripts is te beperken tot twee generieke scripts (naar data file tabellen en terug). Verder heb ik nog wel import en account scripts erin gelaten mocht je toch nog een keer een volledige import willen doen. Sommige dingen zijn wel even wennen (bijv GTRR) maar ook daar zijn redelijk generieke scripts te maken. ik heb even naar je sample file gekeken en dit lijkt mij geen goed voorbeeld om DataSeparationModel op toe te passen. Te veel werk voor weing voordeel omdat het 1 hele specifieke toepassing betreft. Een goede afweging kan je maken door na te gaan waar je je meeste tijd aan besteed: ontwerpen van steeds nieuwe layouts en scripts of puzzelen op ingewikkelde calculaties tussen table occurrances in de relatie diagram. Het kan nuttiger zijn om je te beperken tot het combineren van sterk functioneel gerelateerde tabellen in een paar files. succes Quote Link naar reactie
0 Gido_ Geplaatst: 8 december 2007 Delen Geplaatst: 8 december 2007 Wat me nog het meest in mijn overtuiging sterkt, is dat een aantal gerenommeerde ontwikkelaars er ook van teruggekomen zijn. Tiens, ik kreeg de omgekeerde indruk... www.filemakermagazine.com/videos/data-i ... ssion.html Quote Link naar reactie
0 Jos Hofman Geplaatst: 9 december 2007 Delen Geplaatst: 9 december 2007 Wat me nog het meest in mijn overtuiging sterkt, is dat een aantal gerenommeerde ontwikkelaars er ook van teruggekomen zijn. Tiens, ik kreeg de omgekeerde indruk... www.filemakermagazine.com/videos/data-i ... ssion.html Het probleem met data/interface scheiding is dat veel ontwikkelaars van het beginpunt niet het model goed hebben bepaald en daarom halverwege vastlopen. De extreme consequentie van data-interface is dat je data DOM moet zijn en alle intellegentie buiten je data gehouden moet worden: dus geen berekeningen, relaties, scripts, waardelijsten etc. in het databestand. Dit is zeer wel mogelijk maar houdt in dat er abstracter geprogrammeerd moet worden. Bovendien moet je datafile op veranderingen zijn voorbereid. Voldoende velden en tabellen dus. Ik heb net een project achter de rug waar dit is toegepast en is ook gedemonstreerd op één van de laatste FileMaker Roadshows (Houten) Quote Link naar reactie
0 Maarten Witberg Geplaatst: 9 december 2007 Delen Geplaatst: 9 december 2007 Interessante discussie. De video, het citaat dat Jean gaf ("filemaker is voor eindgebruikers"), het idee van domme data en abstract programmeren en nog zo wat brengt me op de volgende tussenstand: - data separatie is voor gevorderden - het is vooral zinnig bij heel grote en complexe oplossingen Ik snap nog altijd niet hoe je een line items rapport zou kunnen make vanuit een interface bestand met 0 records zonder de layout van dat rapport in de datafile te maken. En zonder gedoe met portalen, want dan beperk je het aantal lijnen altijd tot de portaalgrootte. Het is vast iets makkelijks, maar ik zie het niet voor me. Iemand die de truc wil delen? Quote Link naar reactie
0 JeanWM Geplaatst: 9 december 2007 Delen Geplaatst: 9 december 2007 Je probleem is dat je FileMaker toepassing denkt. Je moet database denken. Dat betekent dat vóór je ook maar begint met coding, je het model moet klaar hebben dat steunt op requirements en businessrules. Vandaar dat een gewone FileMaker toepasing omzetten naar een separation model gewoonlijk ergens verkeerd loopt. Je kunt perfect data ingeven en nieuwe records aanmaken in de GUI file, terwijl daar totaal geen records zijn, geen script en zelfs geen table. Je steunt op command en query. Quote Link naar reactie
0 Maarten Witberg Geplaatst: 9 december 2007 Delen Geplaatst: 9 december 2007 Je kunt perfect data ingeven en nieuwe records aanmaken in de GUI file, terwijl daar totaal geen records zijn, geen script en zelfs geen table. je bent me even kwijt. Ik dacht dat de records in de datafile zaten, en alle layouts, scripts en berekeningen in de GUI file. Maar ik heb even zitten experimenteren, mijn probleem bestaat niet. je kunt met de TO van een externe tabel ook layouts maken en dan zie je die records gewoon in de GUI file. waarom bedacht ik dat nou niet meteen? Quote Link naar reactie
0 JeanWM Geplaatst: 9 december 2007 Delen Geplaatst: 9 december 2007 Ik dacht dat de records in de datafile zaten, en alle layouts, scripts en berekeningen in de GUI file. Ik heb ook niet het tegendeel gezegd. Enkel: Je kunt perfect data ingeven en nieuwe records aanmaken in de GUI file, terwijl daar totaal geen records zijn, geen script en zelfs geen table. Je aangemaakte records zitten dus NIET in de GUI file. De aanpassingen aan data is NIET in de GUI file. De aanmaak van records en de aanpassing van records gebeurt wel in de GUI. Enkel...de records zitten daar niet. En neen, het is ook niet via een portaal... Er zijn daar immers geen records, geen scripts, geen tables. Quote Link naar reactie
Vraag
Zero55
beste allemaal,
ik heb een fm5.5 database geconverteerd naar fm9, allemaal goed en wel gelukt. Maar nu wil ik de data scheiden van de layouts.
Hoe moet dit in de praktijk ingesteld worden in fm dat het layoutbestand de data uit het databestand haalt ?
groeten.
Link naar reactie
29 antwoorden op deze vraag
Aanbevolen berichten
Doe mee aan dit gesprek
Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.