update

[dpm]

Hallo

 

Ik ben op zoek naar de beste werkwijze om een update te implementeren. Het gebeurd regelmatig dat ik ingrijpende veranderingen moet doorvoeren op een database met +/- 25 tabellen. Ik wens dit niet te doen op de wekende database waar iedereen op werkt. Dus moet ik de oude db importeren in de nieuwe db maar hierbij gaat de teller van de “auto enter serial” verloren.

 

Is er een manier om dit te verhelpen of is er een betere manier om een update te organiseren.

 

Hartelijk dank

[hbrendel]

Wanneer je de import handmatig doet: serial handmatig aanpassen.

 

Wanneer je het importeren wilt scripten:

 

http://www.filemaker.com/help/html/scripts_ref1.36.41.html#1047759

[dpm]

Hartelijk bedankt dit werkt prima !

[edc]

Wanneer je de data (tabellen) en de toepassing in 2 afzonderlijke bestanden plaatst kun je zonder problemen zoveel wijzigen aan je toepassing als je maar wilt. Dan hoef je niets te importeren en dus ook geen serials opnieuw in te stellen. Gewoon het toepassingsbestand vervangen en klaar. Eventueel nieuwe velden voeg je manueel bij in het bestand met de tabellen.

[Kees Deelen]

De laatste opmerking van EDC ben ik al eerder tegengekomen. Ik zit met hetzelfde probleem van updaten en de genoemde oplossing spreekt mij wel aan.

Ik zou echter niet weten hoe ik zoiets aan moet pakken. Is er iemand die mij verder kan helpen, misschien met een klein voorbeeldje?

Alvast heel veel dank.

Kees

[dpm]

Ik ben ook benieuwd hoe zoiets werkt

[edc]

Heel kort gaat het als volgt.

* Maak een bestand '_data.fp7'. Definieer in dit bestand alle tabellen en velden. Ten behoeve van sommige berekende velden kan het nodig zijn dat je in dit bestand ook wat relaties moet leggen. Beperk dit echter tot het minimum. De layouts worden beperkt tot één tabelweergave per tabel.

* Maak een bestand '_toepassing.fp7'. Hierin maken we geen tabellen aan. In het relatiediagram plaatsen we de tabellen uit het vorige bestand (via Filemaker gegevensbron toevoegen...) We maken hier tussen de tabellen ook de nodige relaties aan nodig voor de goede werking van de toepassing.

In dit bestand worden dus ook alle layouts en scrips ontwikkeld. Wanneer alles klaar is bezorg je beide bestanden aan de klant.

* Indien na verloop van tijd de klant een lijstje bijvraagt kan je zonder problemen de lijst ontwikkelen bij jou. Je stuurt hem dan via mail het bestand "_toepassing.fp7" met de nieuwe lijst of aanpassing. De klant vervangt zijn "_toepassing.fp7" door de update en hij kan zonder problemen verder werken met zijn data.

30 november 2009 aangepast door Gast

[dpm]

Hartelijk dank

 

Dat ik hier nooit aan gedacht heb

[WJ]

Let wel je loopt ook tegen een heleboel problemen die volgens mijn niet opwegen tegen de voordelen. Als je met meerdere bestanden gaat werken.

 

- Variable zijn per File

- Window behaviour

- go to related

- Account moet je allemaal scripten.

- en nog meer.

 

De kracht van filemaker ligt in de intergratie van data en interface. Als je dat niet wilt zou ik een ander pakket aanraden.

Kortom een heleboel werk en complexiteit erbij. Waarom ? Een import routine met een bestand dat tussen de 2 versies zit is zo gemaakt ? En je data is weer fris.

 

Gr,

wj

[hiker]

Bij veel updates is het noodzakelijk dat er ook velden worden bijgemaakt in de tabellen. Een update beperkt zich dus vaak niet tot alleen de file met layouts.

Hoe lossen jullie dat op?

[edc]

Ik bezorg mijn klanten een korte procedure hoe ze die velden zelf kunnen aanmaken. (Enkel geldig voor beperkte eenvoudige wijzigingen).

[hiker]

Dat heb ik ook wel eens gedaan, maar ten eerste durft niet iedereen dat, ten tweede gaat dat niet op bij runtime versies.

[SuperWimmie]

Wanneer je de data (tabellen) en de toepassing in 2 afzonderlijke bestanden plaatst kun je zonder problemen zoveel wijzigen aan je toepassing als je maar wilt. Dan hoef je niets te importeren en dus ook geen serials opnieuw in te stellen. Gewoon het toepassingsbestand vervangen en klaar. Eventueel nieuwe velden voeg je manueel bij in het bestand met de tabellen.

 

Bij veel updates is het noodzakelijk dat er ook velden worden bijgemaakt in de tabellen. Een update beperkt zich dus vaak niet tot alleen de file met layouts.

Hoe lossen jullie dat op?

 

Precies, scheiding van data en layouts vind ik zelf maar een halve oplossing die gevraagd wordt... Ik ben er geen voorstander van omdat je sommige dingen onnodig moeilijk maakt.

Maar goed, daar gaat het hier niet om.

 

Zelf heb ik een export routine gemaakt, die actuele data uit de oude versie in een map op het buroblad aanmaakt. Met scripting is de bestandspad en bestandsnaam van elk van de tabellen te bepalen en de export kan daarin gedumpt worden.

De nieuwe versie doet precies het omgekeerde. Die leest de opgebouwde export weer in en voila, de nieuwste versie is gevuld met de juiste data.

 

Deze slagen maak ik omdat met deze actie het niet uit maakt waar de Filemaker applicaties staan. Doordat gebruik gemaakt wordt van een vaste plaats op het buroblad, hoef je de gebruiker niet te belasten met de plaats van de applicatie. Dat geldt voor zowel de oude als nieuwe versie.

Met één knop exporteren en één knop importeren ben je alle gegevens aan het overzetten.

 

Een paar aandachtspunten:

a. Eenmaal gebruikte veldnamen moet je hetzelfde houden voor de verdere toekomst.

b. Je moet je verdiepen in de logica van de bestandsnamen zoals Filemaker dat nodig heeft

c. Bij veranderingen van velden, moet de export naar het buroblad-dump worden aangepast, zodat alle velden weer meegenomen worden in de export

d. Berekeningsvelden bij voorkeur niet mee exporteren: kan zeer vertragend werken bij de export.

 

Kijk maar wat je er mee kan, ik vind het zelf goed werkbaar maar het kostte wel wat moeite om het goed gebouwd te krijgen.

[WJ]

Wij hebben de update procedure zelf geschreven maar er is ook een tool van base elements. Heb hier nooit naar gekeken, maar is wellicht interessant.

 

http://www.goya.com.au/updatemanager/download

 

Groet,

 

WJ