Beschadigde bestanden na OS X migratie

[Roger]

Een aantal maanden geleden heb ik de stap gemaakt naar Mac OS X 10.2.x en ben ik FileMaker 6 onder OS X gaan draaien. Volledigheidshalve vermeld ik dat onze FM bestanden gehost worden door FM Server 5.02 draaiend onder Mac OS 9.

 

Gehoste bestanden openen en continu gebruiken door clients onder OS 9 en OS X levert nagenoeg geen problemen op. Het beperkt 'on the fly' ontwikkelen aan de gehoste bestanden evenmin. Ik beperk me dan tot scripting en layouting. Velden definiëren laat ik achterwege omdat andere clients dan bestanden moeten afsluiten. Tot zover dus geen problemen. Echter... het 'serieuze' ontwikkelen doe ik lokaal op mijn werkstation en sinds ik ben overgestapt naar FM 6 en OS X zijn de problemen niet van de lucht.

 

Het begon ermee dat FileMaker pardoes dichtklapte (crashte) als ik bij het ontwikkelen aan bestanden bijvoorbeeld naar [velden definiëren] ging of naar [relaties definiëren]. Maar het gebeurde ook bij andere handelingen. Dit heeft tot gevolg dat je FileMaker opnieuw moet opstarten en dat FileMaker een consistancycheck uitvoert bij alle bestanden die voor de crash geopend waren. Naarmate ik wat langer onder OS X werkte gebeurde dit steeds vaker. Op een gegeven ogenblik was het zelfs zo dat FileMaker al crashte bij het openen van de bestanden. Derhalve besloot ik om maar weer terug te stappen naar OS 9. Startte ik mijn computer op in OS 9 en opende ik diezelfde bestanden dan kon ik ongelimiteerd ontwikkelen aan de bestanden, zonder dat zich ook maar een crash voordeed. Ik spreek hier in de verleden tijd, want inmiddels stel ik vast dat ook onder OS 9 de stabiliteit achteruit aan het gaan is. Inmiddels crasht de OS 9 versie van FileMaker 6 ook geregeld. Zeker als deze onder Classic (OS 9 binnen OS X) wordt gedraaid.

 

Ik vind dit zeer verontrustend. Onze organisatie is compleet afhankelijk van deze FileMaker bestanden. De laatste 8 maanden is er enorm veel aan de bestanden ontwikkeld, zodat teruggrijpen naar een backup van voor die tijd geen optie is. Daarbij vrees ik dat als ik dat wel zou doen, dat het met die bestanden ook weldra mis zal gaan. Het lijkt wel alsof ik compleet opnieuw moet beginnen.

 

Tot zover de achtergrondinformatie.

Mijn vraag is simpel: Is er iemand die deze problemen herkent en zo ja, heb je die problemen kunnen oplossen en zo ja, hoe?

 

Bij voorbaat hartelijk dank voor je reactie!

[AvD]

Ik vrees dat we geen goed nieuws hebben: wat je beschrijft is typisch voor een voortschrijdende bestandscorruptie. Wim Decorte heeft daar heel wat over geschreven en ook Darren Terry is zeer goed met deze materie vertrouwd. Het komt erop neer - maar dat is het slechte nieuws - dat deze bestanden niet meer te vertrouwen zijn en dat je zou moeten teruggrijpen naar wat ze de "golden master" noemen, een soort oer-backup die bij elke developmentfase weggeschreven wordt, en die NOOIT live gebruikt wordt door clients. Als je die niet hebt - en dat geldt voor de meesten onder ons - dan vrees ik dat je best from scratch opnieuw begint. Je hebt nog een kleine kans dat de corruptie in het data gedeelte zit, en dat je die eruit zou kunnen halen door een export in TXT-formaat grondig na te kijken en die dan opnieuw te importeren in een kloon. Darren Terry heeft daar zelfs een speciale tool voor ontwikkeld.

Ik hoop dat iemand anders je beter nieuws kan geven, maar ik vrees ervoor.

 

PS Misschien toch nog een lichtpuntje: hoe gedraagt de databank zich op een ander platform?

[Roger]

Hartelijk dank voor uw reactie. De corruptie zit niet of niet alleen in de data, want ook met kloonbestanden zonder records doet de problematiek zich voor. Kan FileMaker niet verantwoordelijk worden gehouden voor dit soort problemen? Als argeloze gebruiker kan men hier toch niet op anticiperen. FileMaker heeft een herstelfunctie ingebouwd om beschadigde bestanden te herstellen. Uiteraard heb ik deze functie vaak genoeg gebruikt. Een en ander lijkt telkens succesvol te verlopen, maar als ik het goed begrijp dan worden beschadigde bestanden maar deels hersteld.

 

Hetgeen Darran Terry hierover geschreven heeft, is dat terug te vinden op internet?

[AvD]

FileMaker heeft een herstelfunctie ingebouwd om beschadigde bestanden te herstellen. Uiteraard heb ik deze functie vaak genoeg gebruikt. Een en ander lijkt telkens succesvol te verlopen, maar als ik het goed begrijp dan worden beschadigde bestanden maar deels hersteld.

 

Dit is het dus! De Recover-functie is een zeer destructief proces dat ENKEL DIENT OM DATA TE REDDEN uit een als verloren te beschouwen bestand. Een gerecovered bestand mag NOOIT meer gebruikt worden. Dit is hier al uitvoerig toegelicht, maar helaas staat dat niet in de FileMaker handleiding . Integendeel: deze geeft de indruk aan de inderdaad argeloze gebruiker, dat recovery dient om iets te repareren. Dat is dus NIET het geval. Kijk eens in de archieven (o.a. onder recovery)

[AvD]

Hier vind je een goed overzicht van de problematiek:

 

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

[AvD]

Nog meer info over bestandscorruptie en recovery vind je hier:

 

http://www.avd-ci.be/tip049.htm

http://www.avd-ci.be/tip050.htm

http://www.avd-ci.be/tip051.htm

 

en ook nog wat in

 

http://www.avd-ci.be/tip048.htm

 

enne... Van alle ziektes... (zie hieronder...)

 

HTH

[Roger]

Wederom dank voor de snelle reacties! Support via dit forum werkt een stuk adequater dan FileMaker's helpdesk, maar dat terzijde.

 

Ik kan niet geloven dat FileMaker hetzelfde denkt over het gebruik van de herstelfunctie als u en andere 'door de wol geverfde' ontwikkelaars. Het zou toch volstrekt ridicuul zijn dat een bepaalde standaard functie, die als eindresultaat beschadigde bestanden oplevert, zonder enige waarschuwing kan worden gebruikt! Het kan toch niet zo zijn dat je dit soort dingen maar hebt te weten en zo niet, jammer dan, honderden uren werk door het putje. Als dit de stand van zaken is dan is FileMaker ten volle verantwoordelijk voor deze problemen. Dan zou FileMaker toch al eindeloos 'gesued' zijn in de VS. Of ben ik nu naïef?

 

Wat mij ten zeerste bevreemd is dat mijn bestanden goed werken tijdens het dagelijks gebruik (draaiend onder FM Server). Van beschadigde bestanden is tijdens het normale werken helemaal niks te merken. Alle functies werken zoals het hoort. Ik kan me indenken dat een bestand een deukje oploopt door allerlei omstandigheden. Maar wat mij enorm frustreert is dat FM er simpelweg uit knalt i.p.v. dat het aangeeft dat er een probleem is met een bepaald bestand. Als FileMaker nu eens gewoon bleef draaien, dan zou dat de andere geopende files in ieder geval niet effectueren. Nu lopen die bestanden ook telkens een deuk op, met alle risico's van dien. Als FileMaker wel zou blijven draaien terwijl bestandscorruptie werd aangetroffen, dan zou je verwachten dat je kunt herleiden waar het ergens mis is, bijvoorbeeld in bepaalde velddefinities, invoerlijsten, relaties, scripts of layouts. Door hetgeen dat als corrupt kan worden aangemerkt er dan uit te slopen zou je een bestand wellicht nog kunnen herstellen. Nu kun je blijkbaar helemaal niks. Ik kan hier met mijn pet niet bij, vind het volstrekt onacceptabel en begrijp niet dat zowel serieuze gebruikers als FileMaker het er zo maar bij laten. Werken met FileMaker is als spelen met een tijdbom!

[AvD]

Ik kan niet geloven dat FileMaker hetzelfde denkt over het gebruik van de herstelfunctie als u en andere 'door de wol geverfde' ontwikkelaars.

Toch is het zo: Darren Terry werkte bij FileMaker en Marcel de Maria is er nog steeds als gezaghebbende spokesman.

Het zou toch volstrekt ridicuul zijn dat een bepaalde standaard functie, die als eindresultaat beschadigde bestanden oplevert, zonder enige waarschuwing kan worden gebruikt!

En toch is dat zo. Er zijn in het verleden al wel stemmen opgegaan om (1) ofwel deze optie uit het menu te halen en ze onder te brengen in een apart programma ofwel (2) de helpteksten aan te passen aan de realiteit. Daarbij komt nog dat in de tijd van FileMaker 2 de helpdesk van FileMaker zelf aanraadde geregeld een recovery te doen bij wijze van preventief onderhoud. Zoals je gelezen hebt, zijn de auteurs van die raadgeving teruggekomen van dit standpunt.

Het kan toch niet zo zijn dat je dit soort dingen maar hebt te weten en zo niet, jammer dan, honderden uren werk door het putje. Als dit de stand van zaken is dan is FileMaker ten volle verantwoordelijk voor deze problemen. Dan zou FileMaker toch al eindeloos 'gesued' zijn in de VS. Of ben ik nu naïef?

 

Oprecht spijtig dat we niet beter kunnen helpen. Trouwens, veel respons komt er niet op je noodkreet.

[HJK]

weet je ook zeker, dat je deze problemen hebt onder een Windows XP machine?

Ik wil hier geen tweestrijd opwerpen hoor, MAC versus Windows , maar jouw verhaal volgende, werk je steeds met één machine. Als je problemen hebt met bestanden, dan kom je deze 9 van 10 keer ook tegen als je ze hosted via Filemaker Server.

Ik zou het zeker eens proberen op een volledige andere machine en besturingsysteem. Ik wil het evenuteel ook wel op mijn ontwikkelingsysteem proberen, als je daar behoeft aan hebt.

Geef het maar even aan.

[AvD]

weet je ook zeker, dat je deze problemen hebt onder een Windows XP machine?

Ik wil hier geen tweestrijd opwerpen hoor, MAC versus Windows

 

Dit is een heel zinvolle vraag. Trouwens als je goed gelezen hebt, zie je dat ik daar mijn eerste antwoord hierboven ook al mee afgesloten had

Twee zaken hieromtrent: de bestandscorruptie is eigen aan het FileMaker-bestand, en je haalt die corruptie dus NIET weg op een ander platform. Maar het is wel zo dat niet elk platform gevoelig is aan elke vorm van corruptie. Het komt voor dat een databank crasht op Windows zodra je naar een bepaalde (corrupte) lay-out gaat, terwijl die databank probleemloos blijft werken op bijvoorbeeld een Mac. Ik heb zo in het verleden al vaak een bestand kunnen openen op een Mac, terwijl het op Windows niet meer ging. Op die manier waren de data dus te redden, want dat principe blijft natuurllijk: een corrupt bestand mag je niet meer gebruiken. Samengevat: om je data te redden kan je (1) ofwel een recovery proberen ofwel (2) proberen het bestand te openen op een ander platform.

Bedankt dus voor je opmerking: je hebt gelijk, en dit thema hoeft helemaal geen aanleiding te zijn tot een Mac versus Windows gevecht, hoewel...

[rmw]

AvD schreef

 

... Trouwens, veel respons komt er niet op je noodkreet.

 

Je bent ons zoals gewoonlijk ruimschoots voor

[Roger]

Ik heb de afgelopen dagen onder OS 9 ontwikkeld en heb geen enkele vorm van bestandscorruptie kunnen ontdekken. Het hele systeem is zo stabiel als een huis! Ik kan derhalve wel concluderen dat de problematiek zich uitsluitend voordoet onder OS X. Ik heb dit niet alleen op mijn eigen machine getest, ook op andere OS X machines slaat FileMaker continu dicht. Wel heb ik een interessante ontdekking gedaan. Het betreft bepaalde printlayouts van bestanden. Bij het verturen van een printopdracht komt de print incompleet uit de printer. Idem wanneer er direct naar PDF wordt geprint. Allerlei objecten, zoals velden en lijnen ontbreken bij bepaalde layouts. Let wel, alleen wanneer FM onder OS X wordt gedraaid. Deze zelfde layouts geven onder OS 9 nulkommanul problemen.

 

De layouts verwijderen en opnieuw aanmaken helpt niet tegen het onverwacht afsluiten van FM. Het zorgt er wel voor dat opnieuw aangemaakte layouts goed uit de printer komen, hoewel ik al een paar keer meemaakte dat het toevoegen van een extra object aan een net opnieuw ontworpen layout, tot gevolg had dat dat ene net toegevoegde object dan vervolgens weer niet geprint wordt. (Je wordt er soms tureluurs van).

 

Ik vestig mijn hoop op OS X 10.3 oftewel Panther en FileMaker 7. Ik ben me bewust van het feit dat eventuele bestandscorruptie niet gefixed zal worden, maar wie weet, draait alles gewoon weer stabiel net zoals het dat doet onder OS 9. Eén lichtpuntje, de hele printengine van OS X 10.2 is flink op de schop genomen bij de ontwikkelingen van Panther. Dit geeft de burger moed! (Althans, burgers die niet kunnen teruggrijpen naar een corruptloze versie van hun bestanden en die niet nog eens helemaal opnieuw willen beginnen).