bestanden op server en lokaal

[jw]

Filemaker server houdt de bestanden open, maar omwillen van snelheid wil ik bepaalde data lokaal op de harde schijf zetten. Deze is dan opgeslagen in een filemakerbestand dat de gebruik ook gebruikt om de bestanden op de server te openen.

 

Dat gaat allemaal prima. Maar nu wil ik dat de bestanden van de FM-server ook data kunnen doorgeven naar het locate bestand. Echter is er alleen een relatief pad bekend waar deze zich bevindt. Dat is dan op ieder werkstation weer anders.

 

Heeft iemand een oplossing voor een dergelijk probleem?

[AvD]

Het is hier al enkele keren ter sprake gekomen. De deployment die je voorstelt, vinden we niet terug in de Best server practices (een FileMaker white paper te downloaden vanaf de FileMaker-site). Ben je voor de volle honderd percent zeker dat die opstelling uiteindelijk voordeliger zal blijken (snelheid en onderhoud, om van de veiligheid nog maar te zwijgen)?

[Peter Wagemans]

De opstelling die je wil is best mogelijk.

Het is best dat je de locale file gebruikt om het doorstart menu op de server te openen, dat dan op zijn beurt de rest van de bestanden opent. Dat is de snelste manier om alles op te starten. Alle bestanden op de server vanuit het locale bestand openen is veel langzamer, en is moeilijker in onderhoud, vooral met vele mensen die een locaal bestand hebben.

AvD heeft gelijk dat dit niet volgens het boekje is, maar regels zijn er om te breken. Goede FileMaker oplossingen tarten meestal de opgeloegde wetten van de relationele databases, door slim gebruik te maken van lookups - reduntante data, niet volgens het boekje dus.

Van het ogenblik dat een FileMaker oplossing "open" is, speelt het helemaal geen rol meer wat het absolute of relatieve pad is naar een bepaalde file. Als die in de lijst van open bestanden zit, en er zit niet onmiddellijk een copie van het bestand in de huidige "werkdirectory" van FileMaker, zal alles vlotjes lopen. Gebruik je je locale data storage file om de oplossing te starten, is deze reeds open, en zullen relaties die op de naam van deze file zijn gebaseerd, correct "geresolved" worden.

Een locale file kan handig zijn voor het opslaan van:

- gebruikerssettings

- zware graphics en/of scripting routines

- "multi-user" markereing van records, zelfs van records in bestanden op de server

- "off-line" nemen van gegevens (bedenk dat je de optie kan laten niet door te starten naar het menu, maar locaal te blijven met een beperkt geimporteerde data set)

- etc.

 

Nadeel van zo'n locale file is voor de hand liggend. Je moet hem zowel structureel als op data niveau kunnen updaten. De meeste FileMaker oplossingen geraken nooit helemaal af. Heb je 50 gebruikers die een nieuw locaal bestandje moeten krijgen, dat heb je weer de uitdaging en het extra werkt om dat te gaan regelen.

Bepaalde routines kunnen vertragen, vooral wanneer een relatie van de locale file die naar een serverfile loopt, moet "geresolved" worden. Het is voor FileMaker niet onmiddellijk voor de hand liggend dat de file op de server moet gezocht worden. Indien de file niet locaal gevonden wordt, gaat FileMaker het locale IP subnet afscannen voor de file, en dat kan even duren.

Leg je relaties dus naar de files op de server op ip adres, en niet door de file aan te duiden in het locale subnet. Op die manier komt het IP adres van de server in de definitie van de relatie te staan, en wordt de relatie sneller "geresolved". En dat zal je niet in 1 of andere white paper van FileMaker vinden.

 

Wat de veiligheid betreft, bedenk wat je locaal stockeert. Wordt de computer gestolen of gehacked, kan dat gevolgen hebben. Maar dat geldt voor heel wat bestanden.

 

Samengevat zeg ik dat het best kan, maar er zijn een aantal technische zaken waar je op moet letten, en bovenstaande lijst van opmerkingen is niet een definitieve lijst.

AvD's antwword is zeer correct, maar als je het echt nodig hebt, zijn er geen onoverkomelijke problemen. Het is echter geen aan te raden opstelling voor de beginnende FileMaker ontwikkelaar.

[AvD]

Prachtig antwoord van Peter en Clarify dus weer op zijn best (eigenlof stinkt, zeggen ze, maar goede wijn prijst zichzelf!).

Maar weer ter zake: ik zat ook nog te denken aan de FM Server backup schedules. Het lijkt geen beginnersklus om ook dat waterdicht te krijgen voor de locaal bewaarde bestanden.

Voor een launcher file is dat natuurlijk geen probleem: die kunnen we gewoon terug installeren omdat die toch geen data in noemenswaardige hoeveelheden bevat. Voor de andere files voorgesteld door jw lijkt het me problematischer. Als ik de originele posting nog eens herlees, dan zie ik enkel de vraag naar snelheid als argument voor de lokale bestanden. Gaat het echt de moeite lonen?

[jw]

Dank voor jullie reactie.

Het leek mij dat het testbestandje dat ik maakte, op een ander werkstation niet werkt maar ik ga er nogeens mee aan de slag.

 

In dit geval is het om gebruikers, die via internet, inloggen wat meer snelheid te geven uit een lijstje van eigen projecten. Die eigen projecten is natuurlijk voor ieder een ander en wijzigt af en toe per week. Ik forceer dan ook de gebruiker om minstens een maal per week het lijstje bij te werken.