Productie versie

[Kees Deelen]

Clarify-ers,

Ik maak gebruik van FM8.5 Advanced en wil een database maken voor een leden administratie. De ontwikkeling en de uiteindelijke (productie)versie staan op dezelfde (Windows) computer. In de ontwikkel-omgeving maak ik dus de programmatuur en heb daar enige testdata ingetikt. Als de ontwikkeling naar mijn idee goed is wil ik deze versie naar een aparte directory zetten. Deze versie moet ik zo kunnen starten en deze versie moet dus ook met productie data werken (en niet met de ingegeven ontwikkel-data). Als ik de programmatuur later in de ontwikkel-omgeving heb aangepast wil ik de nieuwe versie weer in productie zetten zonder dat er iets met de reeds ingegeven data gebeurt. Hoe pak ik dit aan?

Als dit werkt wil ik later in een netwerk-omgeving met data op een file-server gaan werken en de programmatuur op verschillende clients.

[pjotter]

Ik weet niet voor hoeveel leden de database is en wat je precies wilt bijhouden en voor wat voor vereniging?

ALs je een goede basis versie maak kun je beter een maand langer ontwikkelen zodat er een goede uitgebreide basis staat waar men in kan werken. Je kunt dan gewoon verder ontwikkelen (komma's aanpassen) . Als je echt heel grote aanpassingen nog wilt doen die echt een flinke verandering zijn dan zou ik die invoeren na overleg met bestuur op een bepaalde datum. Overzetten oude data op een bepaalde dag naar de nieuwe en die dan online zetten.

[Kees Deelen]

Pjotter,

 

Een beetje vertraagd wil ik toch nog eens terug komen op jouw reacie.

In de laatste zin zeg jij : 'Overzetten oude data op een beppalde dag naar de nieuwe en die dan online zetten".

Heel mooi maar ik weet hoe ik dat zou moeten doen.

Ik zie ook hier en daar iets over RunTime versies. Is er een soort van stappenplan hoe je dat maakt?

Ik snap wel dat het programma zo goed mogelijk ontwikkelt moet worden, maar de praktijk leert dat er volgende week/maand/jaar vragen komen die een verandering voor het programma betekenen. Ik moet dit dat zonder data-verlies kunnen implementeren.

[pjotter]

Kees,

 

De runtime versie werkt niet op een netwerk maar dat is van later zorg begrijp ik uit je vraag. Over de voor en nadelen van een runtime versie staat voldoende op het forum. Ik bedoelde met mijn opmerking dat je een vereniging versie vaak snel klaar hebt en dan kun je beter 1 of 2 weken langer ontwikkelen. Standaard zit er al voldoende bij filemaker geleverd voor een NAW database (Naam . Adres, woonplaats) Het is maar wat je verder er in wilt maken wat tijd kost. Vandaar mijn vraag voor hoeveel leden en wat voor soort vereniging dan is in te schatten wat je nodig hebt normaal. Kijk ik naar mijn zelf dan heb ik een versie op de server gezet en kan ik van huis uit gewoon alles aanpassen en bewerken.

[Kees Deelen]

Hallo Pjottr,

 

Bedankt voor je snelle reactie.

Ik begrijp dat jij zit te ontwikkelen op een versie waarmee gebruikers op dat zelfde moment zitten te werken.

Ik wil dat niet, want in een verder stadium heb ik X verschillende programma's bij verschillende klanten. De wijzigingen wil ik eerst op een ontwikkel systeem maken en testen en eventueel aan de gebruiker laten zien. Bij goedkeuring van deze gebruiker zet ik dan de versie pas op zijn computer.

En dat moet dus zonder data-verlies.

[Kees Deelen]

Onderstaand mailtje had ik naar Rony gestuurd maar hij vraagt om dit op het forum te zetten, Dus :

 

> Rony,

>

> Via deze weg wil ik graag reageren op jouw antwoordt dat je er

> ''tegen" bent.

> Ik denk dat ik het principe niet helemaal begrijp.

> Maar volgens mij moet je toch altijd je oude data kunnen behouden

> wanneer er een nieuwe versie van een programma komt.

> Een nieuwe versie van WORD betekent toch niet dat alle documenten

> opnieuw ingetikt moeten worden.

> Zo ook bij alle boekhoudprogramma's, spreadsheet enz. enz. enz.

>

> Ik ben op zoek naar een stappenplan wat ik kan hanteren als er een

> nieuwe versie van mijn filemaker programma geinstalleerd moet worden.

> Dus met behoud van reeds ingebrachte data.

>

> Ben benieuwd naar jouw idee.

>

> Groetjes,

> kees deelen

[pjotter]

Hallo Pjottr,

knip

Ik begrijp dat jij zit te ontwikkelen op een versie waarmee gebruikers op dat zelfde moment zitten te werken.

Ik wil dat niet, want in een verder stadium heb ik X verschillende programma's bij verschillende klanten. De wijzigingen wil ik eerst op een ontwikkel systeem maken en testen en eventueel aan de gebruiker laten zien. knip .

Het is niet zo dat ik de hele database elke keer aanpas. Dat is wat ik bedoel met werk een paar weken langer aan een programma. Wat wel kan is bv een extra layout maken, scripts maken, een compleet nieuwe tabel maken die nog niet "zichtbaar " is. enz enz. De basis moet gewoon goed zijn. Vervolgens maak je aanvullingen en importeer je de data na goedkeuring in je nieuwe database.

Succes

[BDK]

er zit niks anders op dan oude data te importeren in de nieuwe toepassing en dat kan volgens mij redelijk probleemloos INDIEN:

 

1. je er voor zorgt dat veldnamen niet veranderen

2. dat relaties (en hun namen) niet veranderen

3. je er voor zorgt dat oude record ID’s niet snel zullen conflicteren met nieuwe record ID’s

 

ad 1.

zolang veldnamen niet veranderen kan een import/exportsessie naar een nieuwe versie redelijk probleemloos zijn door bij import altijd te kiezen voor de optie 'namen vergelijken'.

 

maar helaas, veldnamen hebben de neiging nog wel eens te veranderen... dus is het zaak veldnaamwijzigingen religieus bij te houden.

 

wat daarbij kan helpen: onderscheid maken tussen 'datavelden', 'afgeleide velden' en 'programmavelden' (bij gebrek aan beterweten heb ik die termen zelf maar bedacht). moraal: namen van datavelden mogen niet veranderen, de rest wel.

 

en als dataveldnamen dan toch moeten veranderen, zorg dan dat ze bij het exporteren/importeren makkelijk te herkennen zijn. in filemaker heb je niet de mogelijkheid onderscheid te maken tussen wat ik noem 'datavelden' (de essentiële data), 'afgeleide velden' (de afgeleiden van de feitelijke gegevens, zoals totalen, resumé's en andere berekeningen) en 'programmavelden' (velden die alleen nodig zijn om de toepassing goed te laten functioneren, globalen, waarschuwingen, knoppen etc.).

 

in feite wil je bij een update alleen de datavelden exporteren/importeren, de rest volgt immers vanzelf... en het aardige is dat de datavelden veelal maar een klein en overzichtelijk deel van het totaal uitmaken, dus je zou in theorie met een kleine export/import toe moeten kunnen... het gebruik van de voorvoegsels 'c_' voor calculaties en 'g_' voor globalen helpt dan al enorm, die hoef je dan dus sowieso al niet te exporteren/importeren. ikzelf typ bovendien dataveldnamen in HOOFDLETTERS en de rest in kleine letters zodat de essentiële velden makkelijk te herkennen zijn en dat maakt ook veel uit.

 

ad 2. tja, zie 1. maar dan NOG religieuzer.

 

ad 3. het mooie van record ID's is dat je ze automatisch kan laten aanmaken, maar het probleem is dat dat al snel op een vrij simplistische manier gebeurt; gewoon een volgnummer: 1, 2, 3 enz... en de kans dat er dan ooit een geïmporteerd ID van '345' conflicteert met een bestaand ID van '345' is vrij groot. ikzelf kies er daarom voor redelijk complexe ID's aan te maken mbv een auto-enter-calc zonder vervangen: een combinatie van accountnaam & tijdstempel & automatisch volgnummer...

 

als je het bovenstaande in acht neemt wordt het al een stuk probleemlozer om per versie afzonderlijke export/importscripts te maken en te onderhouden, maar als je had verwacht dat het zo simpel zou zijn als een oud msword documentje te open, helaas...

 

groet, bdk

[Kees Deelen]

Wat gebeurt er als er veldnamen wel veranderen (dit zal niet zo vaak voorkomen, maar toch)?

Wat gebeurt er als er tabellen bijkomen, en als er daardoor relaties bijkomen danwel wijzigen?

Mijn simpele vraag is nog steeds : ik heb een aantal aanpassingen gedaan voor de klant, deze aanpassingen heb ik op kantoor geprogrammeerd en wil de nieuwste versie bij de klant implementeren zonder dat hij data verliest.

Zoek ik het zo moeilijk of is Filemaker hiervoor niet gemaakt.

In het laatste geval moeten we gaan kiezen voor een ander software-pakket, maar dat kan volgens mij niet de bedoeling zijn.

Hoe nu verder?

[hbrendel]

Het is altijd mogelijk om de data over te zetten naar een nieuwere versie via importeren. Dit is betrekkelijk eenvoudig.

 

Wanneer dit vaak moet gebeuren kun je het automatiseren met scripts. Ik doe dat altijd.

 

Wanneer veldnamen gewijzigd zijn, dan moet je echter handmatig ingrijpen. Zet dan (voor de relevante tabel) de optie 'Show Dialog' in de scriptstap 'Import Records' aan voordat je het script uitvoert.

 

Succes, Henk