FM9 ontwikkelen, draaiend hebben onder volledig 8...?

[SuperWimmie]

Ik zie een draadje dat net geen goed beeld geeft voor mijn probleem.

 

Vandaar dat ik mijn vraag heel specifiek maak:

 

a. Ik wil graag ontwikkelen onder versie 9, wetend welke lusten en lasten er zijn. Per slot gaat alles toch door, dus gaan we er in mee.

 

b. Ik heb klanten die (allemaal) met 8.0v3 en Server 8.0v3 werken, of 8.5v1 met Server 8.0v4 opereren.

 

Mijn vraag: Ik ontwikkel niet bij de klant, maar installeer daar af en toe nieuwe updates van mijn applicaties. Zijn de applicaties even stabiel als altijd (dat wil zeggen: gewoon goed!) ?

 

Er zitten nieuwe mogelijkheden in versie 9 waar niet iedereen bereidt is voor te betalen. Kan ik ze een generatie over laten slaan?

[AvD]

Je kan je klanten laten werken met hun lagere versie, maar ze kunnen dan geen gebruik maken van functies eigen aan versie 9. Dat is altijd het FileMaker-standpunt geweest, maar dat maakt in jouw geval niets uit, vermits je de 9-functionaliteiten toch niet gebruikt voor die klanten. Mocht je dat om een of andere reden toch doen, dan kun je ze waarschuwen via een controle op de versie. Ik dacht dat Sanne dat hier al eens toegelicht heeft, met enkele nuttige commentaren van Jean. Zoek maar eens op "lagere versie".

Het is wel zo dat deze situatie veronderstelt dat je met een bugvrije versie van FileMaker werkt, en laat dat nu met de 9, zowel server als client, niet het geval zijn, zoals elders op dit en andere fora reeds uitvoerig is gemeld. Eerst uittesten is dus de boodschap. Dat je daarbij een behoorlijke schok kunt oplopen, heb ik ook al gemeld. En dat daar een wat denigrerende commentaar van een poster op gevolgd is, doet spijtig genoeg afbreuk aan het betrouwbaarheidsgehalte van dit forum.

 

Succes!

[SuperWimmie]

Dankje AvD!!

 

Want dat heb ik toch wel nodig gehad.

 

Want... het werkt niet. Althans, na installatie ging dat 1 dag goed en de tweede dag was het raak. De index van één der bestanden ging fout, waardoor zoekacties compleet de mist in gingen. Gevolg: geen integere database meer.

 

Ik moet ook zeggen dat ik de bestanden niet gerecoverd heb onder versie 8... dat is dus vragen om problemen.

 

Veiligheidshalve heb ik deze klant maar een versie terug gezet, zo veel functioneel verschil zit er nu nog niet in.

 

De volgende klant ga ik testen door versie 9 bestanden eerst te recoveren met een 8.0v3 versie. Voor zover ik kan bekijken gaat het allemaal goed, maar het is en blijft Trail and Error

 

Wordt vervolgd...

[Durk]

Wat is de idee achter recoveren? Lijkt me niet helemaal veilig:

 

(Ik citeer uit de help.)

 

Special notes on recover

 

In general, recovering a file should be reserved for files that will not open, or are displaying index problems. Databases that are returning records incorrectly from a find should be fixed by recover.

 

The Recover command aggressively attempts to correct a file so you can open it and recover your data. To do this, the Recover process may delete corrupt fields, layouts, layout objects, scripts, and data. For this reason, you should only use the Recover command when you cannot open a file. Do not use this command for regular file maintenance.

[SuperWimmie]

Het hele idee achter recoveren is dat het de boel herstelt.

 

Herstel betekent automatisch wijzigen en wijzigen kan zijn iets verliezen.

 

Met nadruk op kan zijn. Hoeft dus niet.

 

Heel zuiver beschouwd zou een recovery als uitgangspunt de absolute basis moeten pakken en alle attributen opnieuw moeten opbouwen. Indexen zijn attributen.

 

Vanwege het standpunt van Filemaker dat FP7 bestanden in basis gelijk zijn gebleven zullen de meeste problemen gaan ontstaan met de attributen. Je merkt het met het openen van een FP7 bestand dat onder versie 8 is gebouwd en waarmee je met versie 9 verder gaat. Er verschijnt een melding dat er iets geoptimaliseerd wordt.

 

Een versie 9 bestand zou dus best goed te recoveren zijn onder versie 8. Maar helemaal zeker weten doe ik dat niet. Daarvoor is de handleiding te onduidelijk en spelen er bij ontwikkelaars te veel emoties zonder onderbouwde testrapporten.

 

Ik geef toe dat ik op mijn gevoel af ga door bij een klant een versie 9 ontwikkeling te laten draaien in een versie 8 omgeving.

De versie 8 omgeving heeft zichzelf daar ruimschoots bewezen, daar mag je best zuinig mee om gaan.

De mix tussen versies is niet optimaal maar toch het proberen waard. Versie 9 is nog niet helemaal op z'n best, dus wachten we nog even op release v1 of v2.

 

Intussen zit ik met nieuwe klanten voor wie het teveel moeite kost om versie 8 aan te schaffen (leg het maar eens uit...) dus is versie 9 geen ontkomen meer aan.

De upgrade van 8 naar 9 wordt als te duur voor te weinig beschouwd.

 

Tsjah... daar zit je dan met 1 product voor 30 klanten. Gezien het vertrouwen over en weer kan ik mij dit soort tests permitteren. Zij weten het, ze melden het, zijn bereid mee te denken en mee te werken.

 

Misschien dat het lukt, dan is de druk er voor het komende jaar er weer af. Dan heb ik dat ruimschoots terug verdiend. Niet alleen in geld, maar zeker ook in tijd. Aan dat laatste heb ik meer gebrek...

[AvD]

Durk heeft vragen bij het recovery-proces. Gelijk heeft ie!

Meer info hier en in de daaraangegeven link naar dit forum.

[Durk]

Durk heeft vragen bij het recovery-proces. Gelijk heeft ie!

Meer info hier en in de daaraangegeven link naar dit forum.

 

Dank voor de info.

 

Nou, ik geloof dat ik het wel meen te weten, nu. 'Recover alleen toepassen op kapotte bestanden om de data te redden, dan de bestanden in de prullenbak' lijkt me de juiste conclusie. Je kennie voorzichtig genoeg zijn, toch?

[SuperWimmie]

Klopt, maar ik mis in die discussie iets heel wezenlijks dat voor mij het verschil maakt of je voor- of tegenstander bent van recoveren...

 

Met welk uitgangspunt ga je recoveren?

Is een bestand aantoonbaar beschadigd, dan is een recovery zeker geen garantie dat hij het repareert. Dat hangt af of de basis niet beschadigd is geraakt, want zodra dat het geval is, kan je niets meer garanderen.

 

Maar ik mag veronderstellen dat als ik een bestand met een stabiele basis in de recovery gooi, dat hij wel netjes voor mij alle attributen opnieuw gaat opbouwen?

Als ik daar niet vanuit kan gaan, zou ik de programmeerkunsten van Filemaker niet meer vertrouwen (wat ik dus wel doe).

 

Het probleem is dat je vooraf eigenlijk niet weet of een bestand helemaal zuiver is of niet. Veelal omdat Windows al niet stabiel is, wie weet hoe vaak een bestand oneigenlijk is afgesloten geweest...

Kwestie van inschatten.

 

Vandaar dat ik in dit specifieke geval tussen versie 8 en 9 het ga proberen. De bestanden zijn (voor zover ik weet) niet beschadigd, het gaat mij om de attributen die geheel passend moeten zijn voor versie 8.

 

Zoals ik al aangaf: Trail and Error. Zodra ik merk dat het risico's gaat geven, ben ik de eerste om het hier te melden. Want daar hebben we met z'n allen flink baat bij, vermoed ik.

[JeanWM]

Maar ik mag veronderstellen dat als ik een bestand met een stabiele basis in de recovery gooi, dat hij wel netjes voor mij alle attributen opnieuw gaat opbouwen?

 

Mag je veronderstellen...maar niet geloven...

 

Zie ook:

http://www.clarify.net/viewtopic.php?t=3492&highlight=recovery

 

Recover is en blijft om data te 'redden'. Niks meer en niks minder.

Recover is vrij agressief.

Als je het gebruikt op een bestand (een niet beschadigd) zal er toch aan de structuur gepeuterd worden.

FileMaker gaat kost wat kost de data proberen te herstellen/recupereren. En soms gaat dat ten koste van de structuur.

Een recover doen voor de lol van recoveren kan dus een beschadigde structuur geven.

Vandaar: data gebruiken, bestand weggooien.

 

Dat een bestand waar dan ook beschadigd wordt is niet (altijd) de fout van FileMaker. De oorzaak kan overal zitten. Zelfs een fan die niet genoeg kan koelen kan al rare effecten geven.

Een tijdelijke hick-up van de HD...

 

En nu we toch even op dat item zitten, een back-up maken is niet genoeg.

CONTROLEER of de back-up wel goed is.

 

Velen vergeten dit, tot ze merken dat een back-up alleen maar het woord is en het ding geen inhoud heeft....

 

Dan heb je BDD.... Buenos dias desastre

[SuperWimmie]

....Recover is en blijft om data te 'redden'. Niks meer en niks minder.

Recover is vrij agressief.

Als je het gebruikt op een bestand (een niet beschadigd) zal er toch aan de structuur gepeuterd worden.

FileMaker gaat kost wat kost de data proberen te herstellen/recupereren. En soms gaat dat ten koste van de structuur.

Een recover doen voor de lol van recoveren kan dus een beschadigde structuur geven.

Vandaar: data gebruiken, bestand weggooien.

....

 

Klopt helemaal, omdat Filemaker zijn structuur ook als data in zijn bestanden opgeslagen heeft liggen. Dat is het mooie en tevens gevaarlijke punt van FM bestanden, er zit veel meer data in waar je helemaal geen zicht op hebt. Scripts, layouts, relaties... allemaal data.

[JeanWM]

Dan is er ook nog het fenoneem dat wij 'sleeping corruption' noemen.

 

Er kan b.v. een beschadiging in een layout zitten.

Stel dat dit een layout is die bijna nooit aangeroepen wordt.

 

Je maakt keurig backups en neemt keurig die sleeping corruption mee, zonder het te weten. Hoelang al ? Geen idee....

 

Op het ogenblik dat je op die bewuste layout gaat terecht komen, gaat FM in crash mode.

 

Geen nood, je neemt de eerste backup - corrupt.

En alle backups daarvoor ook al.....

 

Tijd voor BDD....

 

Hoever moet je terug gaan - tot je een backup hebt van vóór de sleeping corruption. Hoe dat te weten komen ?

 

Voer voor een andere topic denk ik......

[Durk]

Ik denk dat hetgeen dat Jean beschrijft alleen te voorkomen is (want op te lossen lijkt het me niet - eens kapot, altijd kapot) door uiterst secuur de bestandsversies onder controle te houden:

 

Maak een nieuw bestand.

Maak daarvan een backup op CD/DVD.

Werk met het bestand.

 

Moet er iets toegevoegd worden?

Kopie van de backup maken, daarin verder ontwikkelen. Deze nieuwe stand van het bestand op CD/DVD wegschrijven (om het risiko van slecht geworden blokken/stofjes op een hard disk te minimaliseren) en er een kopie van maken. Testen van nieuwe funkties tijdens het ontwikkelen alleen met kopieën doen, niet met het masterbestand.

 

Records uit het oude bestand in de nieuwe kopie importeren. Daarmee verder werken.

 

Het idee is om een soort van maagdelijk 'master' bestand te hebben dat gegarandeerd nooit gecrasht is en waarin zelfs nooit records bestaan hebben en steeds weer nieuwe versies van het bestand te maken, uitgaande van dat master bestand.

 

Dat neemt wel het gemak weg van 'even een veldje op een live draaiende server toevoegen' maar goed, we wisten al dat dat geen geweldig idee is. Je kunt dat wel doen, natuurlijk, maar je moet daarna (zonder gestresste klant aan de telefoon ) diezelfde verandering aan je master doen.

 

Dat lijkt mij theoretisch de meest veilige werkwijze.

[SuperWimmie]

Dat is gelukkig ook zoals ik werk. Bij geen van de klanten zal ik iets gaan programmeren, dat doe ik op mijn eigen kantoor en lever dat vervolgens getest weer uit.

Elke klant begint dus met elke nieuwe versie vanaf mijn ontwikkelde set die nog nooit in productie is geweest.

 

Gelukkig is het mogelijk om op deze wijze een klant ook weer een versie terug te zetten, wat nu dus een perfecte uitkomst is gebleken.

 

Het maken van een echte update-procedure is een flinke klus, maar zeer de moeite waard.

[burggraaf]

Maar...

...stel je doet een recover van een bestand....

...op dat moment KAN het dus zo zijn data, records of anders verloren zijn gegaan...

...en dan is het niet onwaarschijnlijk...

...dat wanneer je deze importeert in een 'goede' kloon...

...je mogelijk ook in dit nieuwe bestand problemen hebt of gaat krijgen...

 

Dus...

 

...eigenlijk is een backup het enige echt betrouwbare recovermiddel...

[SuperWimmie]

Valt wel mee.

Ik importeer dus nooit rechtstreeks uit de oude applicatie naar de nieuwe, maar exporteer uit de oude een complete set aparte bestanden (één per tabel) en importeer dat dan weer in de nieuwe applicatie. Wel even opletten dat je de calculated fields niet exporteert, dat scheelt heel veel tijd.

Indexen, layouts, relaties, scripts, value-lists, verwijzingsgegevens, global fields... die raken allemaal verloren.

Je houdt dan kale data over die wel te controleren is op zuiverheid.

 

Ik heb wel een paar keer zo'n beschadigd bestand gehad (versie 6) en na elke recovery ontstonden er twee extra veldnamen die ik niet thuis kon brengen. Hup, verwijderen, en weer opnieuw in de recovery en jawel, daar stonden ze weer.

Oeps....

 

Het bestandje heb ik opnieuw gebouwd.

Zeker nog met versie 6 een flinke klus, omdat het kopieren van scripts, tabellen en velden niet zo vanzelfsprekend was als het vandaag geworden is.

 

Nog erger wordt het als je in je scripts ineens ascii tekens aantreft. Zo'n bestand is dus echt overleden.

 

Ik hou er dus van om juist regelmatig te recoveren. Op die manier kom je er het snelst achter wanneer het fout zit met het bestand en kan je vaak nog naar een backup teruggrijpen die nog niet al te oud (lees: achterhaald) is.

 

De stabiliteit moet dus proefondervindelijk worden vastgesteld. Ik update mijn klanten dan ook nooit allemaal tegelijk.

 

Maar goed, de discussie was eigenlijk terugbrengen naar versie 8 en gaat ondertussen over het recoveren. Dat is natuurlijk mijn eigen schuld, gezien mijn opmerking dat dit in elk geval noodzakelijk is om het goed werkend te krijgen.

Ik besef steeds meer dat het niet voor iedereen zo vanzelfsprekend is om te recoveren, waardoor deze oplossingsrichting vrijwel afgesloten wordt...

[Peter Wagemans]

BTW, het is geen goed idee om met meer dan 1 FileMaker Pro 9 Advanced te ontwikkelen op een FileMaker Server <9.

Er zijn een aantal zaken die je kan doen - zoals script windows laten open staan en zo - die oudere versies van de server niet gaan updaten als een andere ontwikkelaar ze verandert.

De gevolgen zijn dan nefast. Ik moet hier geen tekeningetje bij maken.

[WJ]

Recoveren verwijdert volgens mij de bad blocks. Deze blocks kunnen data of programmatuur zijn.

 

Een interessante test:

1- Maak een clone van je bestand

2 - Recover dit bestand

3 - Vergelijk het het gerecoverde bestand met de kloon zijn ze precies evenveel bytes dan heb je een goed bestand.

 

Klopt dit ?

 

Groet,

 

WJ

[Rony Rabijns]

Dit is geen goed idee denk ik.

De gerecoverde file is vaak kleiner dan de originele.

[WJ]

Je hebt gelijk Rony.

 

Ik heb net een nieuw bestand gemaakt deze direct een clone van gemaakt en daarna de clone gerecovered en jawel het gerecoverde bestand is kleiner....

 

Heb je dus niks aan.

 

Groet,

 

WJ