Herstellen van een solution

[Johnny]

Het overkomt me nu een paar keer dat ik een op de PC aangemaakte solution in FM8 eerst moet herstellen voordat FMserver op de Mac het bestand wil openen. Elders op dit forum las ik dat iemand anders dit probleem ook had ondervonden en dat herstellen een 'oplossing' was. Deze solution is een FM6 ding geweest, geconverteerd naar FM8 en toen verder bewerkt. D'r zit nogal wat tijd in, dus het opnieuw maken zou een ramp zijn.

 

Mijn voornaamste punt is de betrouwbaarheid van FileMaker. Moet ik er vanuit gaan dat een bestand het herstelprocedures in leven moet worden gehouden? Dan ga ik toch mijn vraagtekens plaatsen.

 

Of is hier iets anders aan de hand en is het mac hosten een bezwaar mbt een op de PC aangemaakte solution? Kan het iets met de autorisatie te maken hebben van de Mac, want ik moet na migratie van het bestand van PC naar Mac telkens de schrijfbeveiliging eraf halen. Dat is op zich geen probleem maar waardoor ontstaat het 'defect'?

 

 

Johnny

[JeanWM]

Recover is een oplossing, alleen, het is een oplossing om de 'data' te redden.

 

Wat doe je nadat je een recover gedaan hebt, in detail ?

[Johnny]

Ik blijf het bestand gebruiken, let wel op de pc was er niets aan de hand.

 

Wat anders moet ik doen, de solution opnieuw maken?

 

Mijn vermoeden is dat de recover de gebruiksprivileges op de mac ongedaan heeft gemaakt en er verder niets aan de hand is. Of toch?

[AvD]

Hé Johnny, ik vrees dat we je toch moeten waarschuwen tegen het gebruik van zo'n gerecoverde versie: lees dit eens.

[Johnny]

Ik heb de stukjes gelezen AvD, heel interessant maar niet geruststellend. Anderzijds vraag ik me af of FM8 in dat opzicht niet veranderd kan zijn, anders gezegd: zou dat ook nog gelden voor FM8?

 

Iets anders is dat ik NIET de melding: 'This file is severely damaged and can not be opened. Use the recover command'. De server op de Mac weigerde het bestand te openen. Even gezocht op dit forum (niet aan gedacht dat de privileges door de Mac net even anders lagen dan op de PC, daar kom je dan later achter) waarop ik ergens de recover tip tegenkwam. Aldus gedaan.

 

Overigens weet ik van een zeer gerenommeerd FM forumlid van dit platform dat in geval van een recover (FM6 tijdperk) soms wordt gekozen voor blijven gebruiken van het bestand als er teveel uren in zijn gaan zitten sinds de laaste backup...

[rmw]

Mijn ervaring is dat het ook helpt om een kloon te maken van het bestand dat niet wil openen en daar alle data uit het origineel in te importeren.

De kloon ging in mijn geval wel open op de server, terwijl de server van het origineel aangaf dat het beschadigd zou zijn. De client versie van FM deed echter niet moeilijk.

 

Ik ben het met AvD en JeanWM eens dat herstellen eigenlijk geen optie is.

 

rmw

[JeanWM]

Je zegt het zelf;

 

...niet aan gedacht dat de privileges door de Mac net even anders lagen dan op de PC......

 

Er kan dus een hidden structure damage zijn, zonder dat je het weet, gezien de vrij agressieve manier waarop FM probeert een bestand te openen.

 

Wat anders moet ik doen, de solution opnieuw maken?

 

Nu niet bepaald, activeer de master file die je gemaakt hebt bij het ontwikkelen van de toepassing.

Hierin importeer je de data. Je kunt zelfs een controle doen op mogelijke

rariteiten vóór je de import doet...

[WJ]

In Filemaker professional training series II kan ik alleen het volgende vinden:

 

Slightly damaged files may be recoverable by creating a compressed file using the Save A Copy As function. Do not use the File Maintenance tool to COmpact or Optimize possibly damaged files. If a file still does not pass the consistency check, perform a recovery of the file. Recovered files should always pass the consistency check and are considered safe to usi in Filemaker 8?

[Johnny]

Kortom: recovery liever niet, maar onduidelijk is wat de gevolgen zijn van een gerecoverde file. De waarschuwingen van AvD zijn niet van de lucht... maar anderzijds zijn er mensen die daar wat luchtiger over zijn, om dezelfde term maar eens te gebruiken...

 

Bedankt!

[JeanWM]

Filemaker, Inc. zegt ook:

 

"The underlying action of Consistency check and Recover is to preserve as much of the data as possible ... These utilities do not guarantee that the file has been completely repaired".

"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.

 

En het gaat verder met...

 

"The Recover command makes an aggressive attempt to reopen a damaged file. It is intended for data recovery, not file repair.

[burggraaf]

"The underlying action of Consistency check and Recover is to preserve as much of the data as possible ... These utilities do not guarantee that the file has been completely repaired".

Lijkt me logisch, natuurlijk geeft Filemaker geen garanties...

...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.

ALS er iets corrupt is, wordt getracht het te herstellen en wordt er mogelijk gedelete (data e/o andere) zodat de file MOGELIJK niet meer werkt. DAAROM kun je de actie beter alleen doen als het echt nodig is. Edoch als er met een recovery data verloren zou gaan is het niet meer dan logisch te veronderstellen dat er dan met de import in een clone ook een onjuiste werking van de database zou kunnen veroorzaken.

The Recover command makes an aggressive attempt to reopen a damaged file. It is intended for data recovery, not file repair.

Da's eigenlijk waar het om draait natuurlijk. Edoch er is een ook een goede kans dat het probleem verholpen is en alles weer naar behoren werkt...

M.a.w. het kan ook best goed gaan en dat gaat het ook vaak (uiteraard afhankelijk van het probleem). 't Is meer van: doe het liever niet en als je het dan toch wilt gebruiken: realiseer je heel goed wat de eventuele consequenties kunnen zijn.

[JeanWM]

Dat is het juist.

Er is geen enkele manier om te weten wát er juist mis liep.

 

Je kunt het bestand openen, tijdelijk gebruiken om de data (of wat ervan overblijft) te beveiligen.

En dat is het.

 

Je weet nooit of er mogelijk een 'hidden damage/error' overblijft, zoals iets dat niet nodig was te herstellen om het bestand open te krijgen.

 

Ogenschijnlijk werkt alles wel in recovered file, kans bestaat dat the hidden beast je vroeg of laat opnieuw in the b**tt gaat bijten.

 

En gewoonlijk is dat op een ogenblik dat je dát het minst kunt gebruiken.

[WJ]

Waar halen jullie deze info vandaan ?

[WJ]

Laat maar in de help.

[WJ]

Je weet nooit of er mogelijk een 'hidden damage/error' overblijft, zoals iets dat niet nodig was te herstellen om het bestand open te krijgen.

 

Ogenschijnlijk werkt alles wel in recovered file, kans bestaat dat the hidden beast je vroeg of laat opnieuw in the b**tt gaat bijten.

 

 

Niet geheel waar je kunt weldegelijk fmdatabases vergelijken

FMDiff

[Johnny]

FMdif? Kun je het even uitleggen?

[AvD]

Je weet nooit of er mogelijk een 'hidden damage/error' overblijft, zoals iets dat niet nodig was te herstellen om het bestand open te krijgen.

 

Ogenschijnlijk werkt alles wel in recovered file, kans bestaat dat the hidden beast je vroeg of laat opnieuw in the b**tt gaat bijten.

 

 

Niet geheel waar je kunt weldegelijk fmdatabases vergelijken

FMDiff

 

Ik bied al op voorhand mijn gemeende verontschuldigingen aan en wil zeker niet grof zijn, maar dit is nu echt misleidende en verkeerde informatie.

[JeanWM]

 

Niet geheel waar je kunt weldegelijk fmdatabases vergelijken

FMDiff

 

Nope:

 

....shows only field changes of the first table created in a file.

 

....the current version of FMDiff only reports differences of the implemented sections.

 

For FileMaker 5, 5.5 and 6 just definition changes for these sections are reported:

 

Fields

Layouts

Scripts

ValueLists

Relationships

 

 

Daarbij komt nog;

 

It compares your current solution against a previous one (or a Clone) and reports the differences.

 

Er is geen sprake van een recovered file, noch van de structuur van het bestand....

 

 

Je blijft nog altijd met een onzekerheid zitten....

(alhoewel ik niet zeker weet welke 'quote' André juist aanwijst....

[AvD]

 

Niet geheel waar je kunt weldegelijk fmdatabases vergelijken

FMDiff

 

@ Jean

Je hebt gewoon gelijk!

Het was wel degelijk bovenstaand zinnetje dat ik - eerder geïrriteerd (ik geef het toe) - als desinformatie heb bestempeld. Ik wil hier geenszins persoonlijke registers opentrekken, maar ik kan het niet goed vinden dat argeloze lezers op dit forum slecht geïnformeerd zouden worden door manifest verkeerde adviezen. Er is geen enkel argument om het gebruik van een recovered file goed te praten en ook maar voor 1 percent te adviseren.

 

Aan diegenen die tegen beter weten in toch willen experimenteren: open een FM-bestand in een editor en bewaar een ASCII-kopie. Open het bestand in FileMaker en wijzig een miniem detail in een lay-out. Vergelijk daarna deze tweede versie van het bestand met een file comparator met het origineel en open daarna in de editor de cluster met de variante. Rommel daar een beetje in met één of twee tekens. Save deze gesaboteerde versie. Open het bestand opnieuw in FileMaker en mijd zorgvuldig de gesaboteerde lay-out. Ga daarna naar... enzovoort. De rest laat zich raden. Het is niet moelijk om FileMaker zo rechtstreeks in de hartstreek te treffen (bedenk wel dat de lay-out bewaard wordt in een Mac én in een Windows-versie en dat het perfect mogelijk is de ene te saboteren zonder de andere te treffen). Ga dan eens naar die lay-out tijdens een replace op het netwerk.

Dit bestand blijft perfect werken zolang je uit die fameuze lay-out blijft of er niet naar verwijst in scripts en buttons. Blijf dan gewoon werken en wacht op de fatale crash met dataverlies. Ga daarna voor een spiegel staan en (...) zonder daarbij (...).

[JeanWM]

...en precies wat ik hier ook vanop mijn kansel zit te prediken....

 

Ik haal daarbij graag de voorbeelden van Gregory Durniak aan:

 

1. a file that crashes only when two guests are on the same list layout, and a script is triggered to set a number field. This file ran for a full year before the corruption was discovered ( All the backups were corrupted ). FileMaker Tech Support was unable to help.

 

2. a file that has an annoying pause after any user action, e.g. clicking a button, finding records, etc. This file is much too large to rebuild.

 

3. a file that runs fine, until you save as clone, and you find that three layouts are missing in the clone copy. This file did not crash. It was damaged when it was copied to an IMac with a faulty hard drive. This file ran for a week before the corruption was discovered.

 

4. a file with over 190,000 records, that suddenly displays "Records: 0", and appears blank, even though these records are still visible in a related portal.

 

Ik propageer niet graag horrorverhalen over FileMaker, maar als (ex) ontwikkelaar kunnen/mogen we niet naast de realiteit kijken.

 

Iedere software is onderhevig aan 'hidden errors'.

 

Wat we kunnen doen is mekaar attent maken op ondervonden zaken, op aan der datalijve ondervonden ervaring.

 

Wat mij evengoed irriteert, agiteert en 'oep maan pjeid doet zetten' is het koudweg negeren van op ervaring steunende feiten, terwijl je bezig bent anderen voor rampen te behoeden.

 

....en nu stap ik van mijn zeepkist.....

[WJ]

Of course, the best action to take when you have damaged databases is to use your best backup (filemaker knowlegde base)

 

Ik geef zeker niet het advies om een recovered file te gebruiken!

Echter soms kan men niet meer anders.

 

Het is altijd het beste om je originele bestand te gebruiken, helemaal mee eens!

 

Ik sluit me volledig aan bij Jean en AvD het is niet de bedoeling geweest om mensen op het verkeerde spoor te zetten. Ik wou jullie alleen op de hoogte brengen van FMdiff mocht je in de situatie verzeild raken dat je een recoverd file moet gebruiken dan heb je misschien wat aan de FMdiff analyses. Het was bedoeld als hulp niet om het gebruik van recovered files te rechtvaardigen.

 

Volgens mij zou je stappen plan er zo uit moeten zien in geval van een beschadigd bestand.

 

 

1 - Gebruik nooit de filemainenace tool

2 - Save een kopie compressed (als dit het probleem oplost ben je klaar? of zouden er dan ook nog fouten in kunnen zitten (Jean/AvD?) vast wel.

3 - Mocht een kopie compressed niet helpen

4 - Recover de file

5 - Doe een export als .csv of tab

6 - Import in master file (origineel)

7 - Heb je geen master file (live development) maak dan een clone van je recovered file

8 - Import de csv's en tab files in clone.

 

Hmm ben ik benieuwd of jullie het met de handelingswijze eens zijn.

 

Groeten,

 

Willem-Jan

[Johnny]

Hm, dat zou nog een aardige zijn.

De vraag die zich bij mij nu opdoemt is: is het voldoende om de records uit de gerecoverde file te halen, de gerecoverde file te clonen en vervolgens de records te importeren?

 

Of moet je de database from scratch weer opbouwen?

 

In dat laatste zit een probleem, want dat is veel werk als je flink wat layouts hebt staan.

 

Een vervolgvraag is: als je from scratch moet beginnen, mag je dan wel met copy&paste de layouts uit de gecrashte file halen of importeer je dan de fouten mee? Hoe gemakkelijk mag je het jezelf maken zonder de mist in te gaan?

[Johnny]

Je mag zeker niet in filemaker formaat exporten uit de gecrashte file denk ik...

[WJ]

De vraag die zich bij mij nu opdoemt is: is het voldoende om de records uit de gerecoverde file te halen, de gerecoverde file te clonen en vervolgens de records te importeren?

 

Of moet je de database from scratch weer opbouwen?

 

Dat is moeilijk te beantwoorden.

 

Je zou recovery kunnen proberen, je weet niet hoeveel schade je hebt opgelopen. Je moet de file goed testen en bekijken. Je kunt analyser erover gooien om te kijken of er technische fouten in zitten.

En misschien kun je iets met FMdiff zelf nooit gebruikt maar je kunt misschien de clone vergelijken met een oude backup van een oudere versie.

 

 

Hieronder zie je de voorgestelde handelingswijze van Filemaker Knowledge base voor het recovery proces.

 

 

Question

How To Organize The Recovery Process When Recovering Related Databases

 

Answer

 

APPLICABLE TO

FileMaker Pro 8, FileMaker Pro 7, FileMaker Pro

 

When running a recovery process on databases in a FileMaker Pro solution, (multiple databases using relationships to one another) retaining the original filenames is crucial to maintaining the integrity of the relationships between files. Following is a overview of a process to help organize the recovery process and avoid filename confusion.

 

Of course, the best action to take when you have damaged databases is to use your best backup, if however you find that you do not have a usable backup use the following process to recover FileMaker Pro databases that are part of a related solution. This process can also apply to a flat file that does not use relationships.

 

Get Ready

 

To begin, you must be sure the databases are not being hosted via FileMaker Server or being used by any other copy of FileMaker Pro such as in a networked environment. Make sure no other applications are running such as virus protection, screen savers, etc. A clean booted machine with only basic system processing is highly recommended.

At the root level of your system, not the desktop as this is actually buried down in the folder structure, create a folder with an easily recognized name, such as the date. Within this newly created folder create four folders:

Original – This will eventually hold your original databases.

Recovered – This will eventually hold your newly recovered databases.

Clones – This will eventually hold newly created clones of your databases.

Data – This will eventually hold the exported data files from your databases.

 

Isolate the FileMaker Pro databases you are planning on recovering by moving them into the folder named Original. Launch FileMaker Pro. Make sure both the databases and the application are all on the same computer and that you are not actually accessing either over the network. You might also consider whether you are using an external drive. In the long run it is best to use as simple a setting as possible leaving little room for error such as the external drive accidentally being disconnected in the middle of a recovery process.

Recover and Rebuild

 

Launch FileMaker Pro. From within FileMaker Pro choose File menu > Recover and recover your FileMaker Pro databases saving them into the folder named Recovered making sure to rename them exactly as the original filename. For example; during the recovery process FileMaker Pro will rename MyFile.fp7 to MyFile Recovered.fp7. You should rename it MyFile.fp7.

Once you are done recovering all databases rename all the originals from within the Originals folder adding BAD to the end of each one. For example; MyFile.fp7 in the Original folder would be renamed to MyFile.fp7 BAD. Rename the file at the operating system level NOT from within FileMaker Pro.

From within FileMaker Pro open all the databases in the Recovered folder and one-by-one save a clone of each one saving it into the folder named Clones again using the original name not the renamed version with Clone added. For example; during the cloning process MyFile.fp7 is renamed to MyFile Clone.fp7 you should rename the database MyFile.fp7.

To filter out any remaining damage in the data, one-by-one open the databases in the Recovered folder and export all data to either Tab-Separated Text, or Comma-Separated Text format files again naming the new text file using the original database name. One exception here, if you are using the extension .fp7 change this to either .tab for Tab-Separated Text or .csv for Comma-Separated Text to further organize the process. Save these new data files to the folder named Data.

Close all the recovered files that are open after exporting the data to text files.

One-by-one open the database clones in the Clones folder and import the corresponding data file from the Data folder making sure to match the data to the correct fields. For example; open MyFile.fp7 from the Clones folder. It will be an empty database. Import the MyFile.csv file from the Data folder into this clone.

At this point all the databases that are in the Clones folder can be considered your final recovered databases. Move these to the location used for daily usage.

It is a good idea to keep the original databases for a short time until you are comfortable that the recovery process did not eliminate necessary structure or data.

[WJ]

Je mag zeker niet in filemaker formaat exporten uit de gecrashte file denk ik...

 

Klopt beter csv of tab.

[Johnny]

Bedankt WJ en degenen die ook hebben gereageerd, het onderwerp is goed uitgelicht nu...