Het meest valabele argument voor de single file solution?

[AvD]

Stel een oude 6-solution bestaande uit een 70-tal files. Wordt die "probleemloos" geconverteerd naar 7 of 8, dan zijn we al heel gelukkig: alles draait nog...

Maar uiteraard zitten we dan nog met die 70 files. Af en toe moet er eens een wachtwoord gewijzigd worden. Zonder plugin of externe tool is dat dan enkele uurtjes klikken... Maar daar blijft het ook bij. Op het ogenblik dat de vorkheftruck door de stroomcabine rijdt, zijn er ook maar twee van de zeventig bestanden te vervangen door een "backup + recovery"-procedure.

 

Welke argumenten kunnen we aanhalen om te pleiten voor de niet te onderschatten investering om toch naar een single file solution te gaan? Daarbij denken we wel in de eerste plaats aan ROI.

[JeanWM]

Vanuit veiligheids oogpunt kun je gelijk hebben Andrè.

 

Een toepassing met zoveel files zou ik ook 'afzonderlijk' houden.

 

In mijn schooltoepassing heb ik alles wat strikt met studenteninformatie te maken heeft in 1 file (was 6 bestanden).

Het financiele in een andere (10 bestanden).

De 'school' is ook afzonderlijk ( 8 bestanden).

Het kwaliteitsysteem is afzonderlijk (23 bestanden).

De 'leerstof' is afzonderlijk (34 bestanden)

De 'resultaten' ( 16 bestanden).

De rest van de zaak (19 bestanden)

 

Ze zijn wel relationeel verbonden, met een overkoepelende 'preference' file die per gebruiker de verschillende toegangsprivileges regelt.

 

De vorkheftruck mag dus door de stroomcabine gaan, wat hier nogal dikwijls voorvalt tenandere.

Mijn beveiliging is een 'noodstroom' die mij 17 minuten batterijelectriciteit geeft, zodat we ruim de tijd hebben alle bestanden/pc's op een deftige manier af te sluiten. Het was ooit anders....

 

Ik ben niet de conversietoer opgegaan voor alle bestanden, 3/4 is van scratch begonnen.

Ik heb wel een poging ondernomen, maar heb het na tal van mislukkingen opgegeven. De 7/8 is eigenlijk te nieuw/anders om op dezelfde manier te blijven werken.

 

Het geheel in 1 single file gieten...het is te doen, maar ik denk dat ik dan heel wat flexibiliteit zou kwijt geraken.

Nu is alle 'gelijkaardige' info zowat bij elkaar in 1 file. Bij sommige is zelfs de data gescheiden van de 'motor'. Was eerder een 'uitproberen'.

 

Het geheel in afzonderlijke bestanden houden, zoals in FM6, zou geen meerwaarde gegeven hebben, gezien we dan eigenlijk geen maximaal gebruik hadden kunnen maken van de nieuwe geboden mogelijkheden.

 

Alles bij elkaar denk ik hier een goede combinatie mee gevonden te hebben van 'ease of use' met 'security' en 'use of new features'.

 

Natuurlijk werd het geheel 'in huis' gedaan. Het zijn niet te recupereren kosten (zowat 6 maanden werk). Ik begrijp dus goed het dilemma van prof ontwikkelaars die de kosten dienen door te rekenen.

 

Voor een aantal klanten zit ik in hetzelfde schuitje. Alhoewel ik hier het voordeel had dat FM niet zo bekend was en de gekregen opdrachten net in de 'overgangsperiode' vielen, wat de mogelijkheid gaf om onmiddellijk over te schakelen naar 7/8, nog voor de projecten volledig af waren.

De impact was er wel, maar eigenlijk te verwaarlozen.

Terug te brengen tot een kleine vertraging in de aflevering.

 

Indien je van 0 begint is het natuurlijk gemakkelijker om alles in 1 bestand te houden, het werkt sneller, maar ik denk dat je toepassing dan kwetsbaarder is. Niet zozeer vanuit FileMaker zelf, maar eerder door externe factoren.

 

Dus eigenlijk, feitelijk, pleit ik NIET voor een 'alles in 1' toepassing.

Meer voor fruit allemaal bij elkaar, maar dan wel appels bij appels, bananen bij bananen, krieken bij krieken.....

 

2 centavos por motivos personales.

[burggraaf]

Er hebben hier zich al diverse argumenten in de diverse onderwerpen de revue gepasseerd. Maar in dit kader:

...niet te onderschatten investering om toch naar een single file solution te gaan?

 

Is het toch voor velen een heel sterk argument om het toch maar niet te doen... Conform de formule: veel tijd = veel geld

 

Verder: als je een goede backup voorziening hebt mag m.i. in principe niet uitmaken of je nu 1 of 70 bestanden moet restoren. Als 1 van de 70 bestanden toch niet meer te repareren blijkt kan er ook een heel groot probleem zijn. Een 'goede backup voorziening' is een statement: vaak ontbreekt het hier aan.

 

Er zijn nog meer argumenten om het wellicht niet de doen: de omvang van sommige bestanden en de mogelijke relaties welke allemaal in 1 relatietabel komen wat wellicht onoverzichtelijk wordt.

 

In alle andere gevallen (de persoonlijke voorkeur): zoveel mogelijk in één bestand dat maakt het voor de ontwikkelaar toch wel een stuk praktischer.

 

Het probleem zit 'm meer in: als de klant het verschil niet echt merkt is deze dan wel bereid om hierin te investeren? (gaat-ie het wel merken is het een argument). Wat je zou moeten kunnen aantonen is dat als de klant het niet doet dat hij veel tijd en kosten bespaart bij aanpassingen of dat de applicatie technisch beter/sneller functioneert en blijft functioneren.

Veel van deze argumenten vergen echter vaak veel verkooptalent...

[AvD]

Dank aan Jean en burggraaf voor hun reacties. Ik kom er nog op terug, maar ze bevestigen toch al wat ik zelf dacht.

 

Wat de recovery betreft: ik zou me minder ongerust voelen als ik pakweg drie of zelfs 10 van de 70 bestanden zou moeten recoveren om de data eruit te halen, dan dat ik dat zou moeten doen voor een evengrote single file solution. Dat is toch heel wat meer werk. Bovendien weet je nooit waar precies de digitale veeg uit de pan terecht gekomen is: in het data-gedeelte? in het engine-gedeelte? in allebei? in een script? in een lay-out? in 8 lay-outs? in 16 scripts?

 

Bangelijk noemen ze dat in Antwerpen...

[Koen Van Hulle]

Ik zit volop in een conversie/migratie van een 50 bestanden oplossing naar FileMaker 8. Dit loopt vrij vlot.

 

Ik ga in deze conversie niet naar een 1-bestandsoplossing, maar naar iets wat er tussen in ligt. Ik heb mijn toepassing momenteel gereduceerd tot een 25 tal bestanden.

 

De tijd die daarin stopt valt reuze mee. Vaak is het minder werk om een bestand samen te zetten, dan om scripts te gaan debuggen die in de knoei zitten met niet gelocked records, vensters, ...

 

Hoe ben ik tewerk gegaan?

 

1. Na conversie alle file references uitkuisen.

2. Een rapport gegenereert in de FileMaker Pro Advanced

3. Een databankje gemaakt die alle filereferences bevat. (Dus 1 tabel, 3 velden): Bestandsnaam, refenntienaam, referentiebestand

 

Alvorens 2 bestanden samen te zetten doe ik het volgende in de te wissen bestand:

1. Hernoemen van occurences, met een prefix voor, zodat we zeker zijn dat de Occurences die we aanmaken NIET reeds bestaan in het eerste bestand.

2. Hernoemen van de scripts: met een prefix voor, zodat we geen verwarring hebben.

3. Hernoemen van de layouts: met een prefix voor, zodat we geen verwarring hebben.

4. Waardelijsten hernoemen.

 

Vervolgens doe ik de volgende stappen in het samengevoegde bestand

1. Importeren van de tabel

2. De relatiegrafiek terug aanmaken, en de commentaren in de calculaties verwijderen.

3. Van elke layout die bestaat in het brondbestand, een lege layout aanmaken in het doel bestand, gebasseerd op de nieuwe occurence.

4. Scripts importeren

5. Layout elementen copieren van de ene file in de andere file.

6. Alle scripts testen en aanpassen waar nodig (nieuw venster, ga naar layout toevoegen, ...)

 

Alvorens het tweede bestand te wissen, zoek ik in de databank alle bestanden op die een file reference hebben naar het te wissenbestand:

1. Aanpassen occurence naar nieuw bestand

2. Aanpassen externe scripts naar nieuw bestand (kan je vinden in je rapport)

3. Wissen van de file reference.

 

En alles testen.

 

Je zult zien in vele gevallen valt dat werk best mee, omdat veel FileMaker 6 bestandjes, in zo'n grote oplossing niet zo complex zijn.

 

Probeer de bestanden samen te zetten naar logica. (vb Klanten, Contacten, Afdelingen, ... of Facturen, Factuurlijnen, Bestelbonnen, Bestellijnen).

Maar ik zou niet gaan naar een één bestandsoplossing, iets wat ik bij mijn nieuwe FileMaker 8 oplossingen meestal ook niet doe.

 

Groeten,

 

Koen

[AvD]

Hé Koen, bedankt. De raadgevingen die je hier geeft zijn zo belangrijk dat ik die graag in het documentatiegedeelte zou zetten. Akkoord?

[Koen Van Hulle]

Akkoord.

 

Koen