Consolideren data source met interface

[TheMisfit]

Ik heb een dbase betsaande uit 2 bestanden (1 met alle datatabellen en 1 met alle interfacecomponenten).

De opsplitsing bleek achteraf een grote blunder en ik wil nu terug tot 1 bestand komen (omdat ik de dbase binnenkort aanzienlijk moet gaan uitbreiden)

 

Hoewel FMA 11 tabellen kan importeren blijven de onderlinge relaties daarbij niet behouden.

Zelfs als je na de import de TO van een externe tabel vervangt door die van de nieuw lokaal geïmporteerde tabel loopt het mis.

O.a. alle berekening die gebruik maken van relaties zijn om zeep.

Hoe pak je zoiets aan , je kan toch moeilijk veld per veld alles terug gaan instellen?

dan kan je net zo goed opnieuw beginnen.

 

Ik ben echt ten einde raad

[hbrendel]

Probeer het volgende. Ik weet niet of het overal voor helpt, maar dit zou je op weg kunnen helpen.

 

Zorg dat de tabellen identiek zijn, dit kun je doen door kopiëren en plakken. Importeer de inhoud.

 

Ga naar de Relationship Graph. Klik nu op de oude Table Occurrence. Kies hier nu de nieuwe gegevensbron. Zorg dat de naam van de relatie hetzelfde blijft, deze pleegt te veranderen als je een andere data source kiest.

 

Je moet dus niet de lijn naar een andere TO laten gaan, dan ziet FM dit als een nieuwe relatie. Bij mijn manier blijft het voor FM dezelfde relatie.

 

Bij het kopiëren van layouts moet je ook omzichtig te werk gaan. Zorg dat je een blanke layout hebt die gekoppeld is aan de nieuwe TO. De veldnamen moeten gelijk zijn aan die in de te kopiëren layout. Als dat OK is kun je de layout kopiëren tussen bestanden.

 

HTH

[TheMisfit]

Probeer het volgende. Ik weet niet of het overal voor helpt, maar dit zou je op weg kunnen helpen.

 

Zorg dat de tabellen identiek zijn, dit kun je doen door kopiëren en plakken. Importeer de inhoud.

 

HTH

 

Het is daar al dat het misloopt want op het moment dat ik de tabellen importeer,

is de graph nog niet aangepast en zijn de berekeningen die relaties gebruiken dus al om zeep.

 

Field blabla.. missing

 

Filemaker importeert of plakt de tabellen ook 1 na 1 dus op het moment dat ik de eerste tabel importeer kan ik geen berekening importeren die gebruik maakt van een relatie met tabel 2 laat staan met tabel 50.

 

Een beetje de kip of het ei dus

[TheMisfit]

Is er iemand in het bezit van FMRobot 2 voor Windows die (tegen betaling) beide files voor me wil samenvoegen?

Het gaat om 11 tabellen met tussen de 11 en 89 velden die in een bestaande frontend moeten komen.

Enkel de tabellen en de relaties moeten overgebracht worden (geen scripts, geen custom menu's of functies en ook de data mag volledig worden verwijderd)

[WJ]

Hoi,

 

We hebben fm robot maar ik zou je aanraden opnieuw te beginnen

Sorry maar dat is toch de beste weg.

 

Groet,

 

WJ

[TheMisfit]

Hoi,

 

We hebben fm robot maar ik zou je aanraden opnieuw te beginnen

Sorry maar dat is toch de beste weg.

 

Groet,

 

WJ

 

Hoezo werkt dat dan niet zoals geadverteerd?

Voor zover ik begrijp scripten ze de aanmaak van tabellen, velden en relaties op basis van de info in het (XML)DDR.

Dat zou toch perfect kunnen werken lijkt me.

 

PS: hoewel ik een subscription heb op dit topic, ontvang ik geen mail bij een nieuwe reactie,

daarom dat ik soms wat laat reageer. Is daar iets aan te doen?

[Jeroen Aarts]

De opsplitsing bleek achteraf een grote blunder en ik wil nu terug tot 1 bestand komen (omdat ik de dbase binnenkort aanzienlijk moet gaan uitbreiden)

Dit fascineert me wel. Waarom bleek het een blunder?

 

Jeroen

[TheMisfit]

De opsplitsing bleek achteraf een grote blunder en ik wil nu terug tot 1 bestand komen (omdat ik de dbase binnenkort aanzienlijk moet gaan uitbreiden)

Dit fascineert me wel. Waarom bleek het een blunder?

 

Jeroen

 

Omdat dat dikwijls leidt tot dubbel werk.

Je gebruikt je relationships-graph immers zowel in de frontend (want daar zitten je portals, je scripts, je valuelists etc...) als in de backend (want daar zitten alle velden en berekeningen).

Dat betekent dat je je relationships-graph in beide files synchroon moet zien te houden.

Wanneer de toepassing wat groter wordt, blijkt dat niet rendabel.

 

Jan

[Jeroen Aarts]

Bedankt voor je reactie! Het klopt dat in FileMaker de scheiding tussen data en interface niet rigoureus is. Nochtans hebben wij zeer goed ervaringen met de scheiding data-interface, zelfs met grotere toepassingen (100+ tabellen, tientallen gebruikers, ...). Het is zelfs zo dat ik het jammer vind dat voor oudere grotere systemen net nog niet de scheiding toepasten. Wij bouwen sowieso vaak aparete TO groups voor veldcalculaties en value lists, en voor ons is het extra werk verwaarloosbaar (hoogstens wat meer klikken)

 

Grote voordelen zijn volgens mij toch o.a. een verbeterd versiebeheer, gemakkelijker te beheren als je met meerdere developers tegelijk werkt, ...

 

Jeroen

[WJ]

Hoi,

 

Wij hebben een standaard oplossing zonder data en interface scheiding.

We updaten onze oplossing ongeveer iedere 2 maanden dit gaat prima.

Wij zijn juist blij dat we maar 1 file hebben. Maar ja alles heeft zo zijn voor en nadelen.

Voordelen zijn volgens mij

 

- eenvoud in

- rechten

- scripting

- global variabelen

- geen dubbelwerk

- bestandsbeheer

- 1 bestand updaten (e-mailen/ftp/backup etc)

 

- Optimaal gebruik maken van de functies

- alles werkt in 1 file in meerdere werkt het niet altijd meer.

 

- Performance

- weet ik niet hoe dat zit ?

 

Nadelen

- Update procedure.

- Geen risicospeiding van bestands corruptie (nog nooit meegemaakt)

 

Misschien is het leuk dit lijstje met voor en nadelen uit te werken. Dit is een opzetje en ik ben natuurlijk bevooroordeeld.

Groet,

 

WJ

[TheMisfit]

FYI: Intussen is het me wel gelukt de twee files te consolideren.

 

Ik had de TO's van de originele RG wel allemaal op de geïmporteerde tabellen ingesteld,

maar was vergeten de context van de calculaties in te stellen op diezelfde TO's.

De vele fouten die ik in de import.log terugvond waren hiervan een rechtstreeks gevolg (hij vond geen enkele gerelateerde tabel vanuit die geïmporteerde/vrijstaande TO's.

 

Ik heb daarom voor het weggooien van elke (geïmporteerde/vrijstaande) TO netjes de context van alle calculaties aangepast en na het verwijderen

een DDR in XML gemaakt en gezocht op "missing", op die manier was ik zeker dat ik geen enkele calculatieaanpassing vergeten was.