Meerdere bijlagen opslaan, wat is de manier?

[Roger]

In een tabel [dossier] is het nodig een variabele hoeveelheid bijlagen bij de records te kunnen archiveren. Wat is hiervoor de beste manier: Een aparte tabel voor de bijlagen? De Troi File Plug-in (of een andere plug-in)? Of is er nog een andere (betere) insteek?

 

Wat gebeurd er eigenlijk met de grootte van de database als er veel bijlagen in containers worden opgeslagen?

 

Ik krijg graag een duwtje in de goede richting!

[andries]

He Roger

 

dit is zowat mijn stokpaardje

 

sla je attachments op in een aparte file (Attachments.fp7) of liefst nog op een fileserver en sla ze dan op als reference in die aparte file.

 

Zo een file heeft dan 1 tabel met volgende velden (kunnen er meer zijn he: AccountName Created, beschrijving document, etc):

 

- een uniek ID

- een container veld

- een referentie naar de record waar je de attachment aan wil vasthangen (of kan zelfs een multikey zijn)

 

Aan elke tabel waar je attachments voor wil opslaan, hang je gewoon een table occurrence van die Attachments tabel aanvast. Zo kan je zoveel attachments per project opslaan als je wil. Ik heb zo een file ontwikkeld en voorgesteld op FMSummit 2010, en die werkt zonder gebruik van een plugin. Het is een beetje werk (ben je toch 2-3 dagen aan aan het ontwikkelen), maar je kan die file nadien voor eender welk project gebruiken en je hebt zo een attachment module geimplementeerd in minder dan 5 minuten.

[Roger]

Hi Andries,

 

Bedankt voor je snelle reactie!

 

Een aparte file dus. Dat lijkt me inderdaad slim wanneer je bijlagen opslaat in containervelden, maar minder noodzakelijk als je opslaat als reference. Een paar vragen:

1. Waarom zou je de bijlagen het liefst op een aparte fileserver opslaan? Een beetje server met raid moet dat toch prima kunnen handlen?

2. Hoe zit het met het gebruikersgemak wanneer je opslaat als reference? Moet je dan eerst handmatig de gewenste bijlagen handmatig naar een centrale plek op de server plaatsen voordat je gaat koppelen? Het is immers niet wenselijk dat bijlagen lokaal op werkstations van gebruikers blijven staan met het risico dat deze worden weggegooid of niet beschikbaar zijn omdat een gebruiker een vrije dag heeft en zijn computer niet aan heeft staan.

3. Je geeft aan dat zo'n aparte file bouwen nog vrij veel werk is. Waar zit 'm dat dan in? Het lijken mij, zoals je zelf al aangeeft, maar een paar velden die je hiervoor nodig hebt?

 

Ik hoor graag van je. Hetgeen je op het summit hebt voorgesteld, is dat misschien nog ergens te bewonderen?

 

Groet, Roger

[andries]

He Roger

 

 

Om op je vragen terug te komen:

1) FileServer: soms is het gewoon gewenst en heeft een klant al een fileserver waar je je files op moet bewaren. Anders maakt het niet veel uit. Wat je wel wil in een multiuser omgeving is dat iedereen aan de files kan dus moet je ze wel centraal opslaan (zie punt 2).

2) Ja, maar dat doet dus die file voor mij. Mijn mechanisme is als volgt: ik laat de gebruiker een file kiezen, en sla die tijdelijk op in een container. Ik bereken het pad waar de file naar toe moet (waar iedereen er bij kan = centrale plek), exporteer die tijdelijk opgeslagen file en importeer de file weer als reference (dit kan eigenlijk nog geoptimaliseerd worden). Nadien de file openen is dan een simpele Send Event script stap.

3) het bouwen van zo een file zelf duurt niet lang, maar wel de scripts en functionaliteiten ontwikkelen als je die overal wil kunnen gebruiken. Op dit moment is de file die ik heb ontwikkeld zover gevorderd dat ik op twee minuten een upload/download naar een fileserver, webserver of FTP server kan implementeren in elk nieuw project. De file handelt dan alles af gaande van management van de folders, toegangsrechten en dergelijken. Om het te implementeren in een project moet ik 1 ding doen: Add External Data Source, nadien is het gewoon telkens als ik een attachment wil opslaan, het hoofdscript aanroepen van die file (met juiste scriptparameters), en die file handelt dan al de rest verder af. Binnenkort (een maandje) hebben we een video online over deze file. Ik hou je dan op de hoogte, zodat je kan zien wat ik hiermee bedoel. Eigenlijk hangt het er hier van af of het one time shot is of dat je denkt dat je dit nog gaat nodig hebben in de toekomst.

 

De file heb ik even getoond op FMSummit in kader van een andere sessie (herbruikbaarheid van code). De file mag ik jammer genoeg niet zomaar delen.

[Roger]

2) Ja, maar dat doet dus die file voor mij. Mijn mechanisme is als volgt: ik laat de gebruiker een file kiezen, en sla die tijdelijk op in een container. Ik bereken het pad waar de file naar toe moet (waar iedereen er bij kan = centrale plek), exporteer die tijdelijk opgeslagen file en importeer de file weer als reference (dit kan eigenlijk nog geoptimaliseerd worden). Nadien de file openen is dan een simpele Send Event script stap.

 

Daar zit 'm de crux. Ik vermoed zomaar dat er plug-ins zijn die deze taken automatisch verzorgen. Ik ga daar toch eens naar kijken. In elk geval hartelijk dank voor je reacties. Het einddoel is me nu in elk geval helder. Nu de weg er naar toe nog aanleggen.

[SuperWimmie]

2) Ja, maar dat doet dus die file voor mij. Mijn mechanisme is als volgt: ik laat de gebruiker een file kiezen, en sla die tijdelijk op in een container. Ik bereken het pad waar de file naar toe moet (waar iedereen er bij kan = centrale plek), exporteer die tijdelijk opgeslagen file en importeer de file weer als reference (dit kan eigenlijk nog geoptimaliseerd worden). Nadien de file openen is dan een simpele Send Event script stap.

 

En precies zo doe ik het dus ook.

't Werkt heel goed en de Filemaker files blijven lekker klein.

[andries]

ik zie het nood van een plugin niet, buiten om mss folders aan te maken en dergelijken...

 

De export field contents script stap van FileMaker werkt perfect en FileMaker biedt echt alles om je attachments te gaan beheren.

[Ari]

Dit klinkt hartstikke goed en ook goed uitvoerbaar voor de gemiddelde FM programmeur. Ik zou graag nog een stap verder gaan door emails met bijlagen te kunnen inlezen waarna de bijlagen automatisch op bovengenoemde wijze worden opgeslagen.

 

Is dit volgens jou technisch haalbaar binnen FM Andries?

[Johnny]

Dit is een interessant item. Ik zit al tijden te broeden op een goede oplossing.

 

Als ik het goed begrijp worden de attachments als het ware via FM getransporteerd naar een centrale plek waar iedereen in een multi-user omgeving erbij kan. Ik stel vast dat er dan 2 exemplaren van het betreffende attachment bestaan: 1 op de originele plek en 1 op de 'centrale' plek. Wat nu als een gebruiker het attachment (bijv. een *.doc) bewerkt (op de originele plek)? Dan zit je met het probleem dat er opnieuw moet worden geïmporteerd wil je de zaak synchroon blijven houden. Of je zou alleen bewerkingen moeten uitvoeren via FM. Maar dan zou je het attachment op de orginele plek moeten wissen, anders krijg je toch vergissingen.

 

Ik ben er nog niet uit...

 

Hoe exporteer je eigenlijk een record op de FM server, bij mij komt hij altijd op het lokale station terecht, niet op de server.

[Ari]

Op het moment dat je het bestand vanuit het containerveld in een directory hebt gezet kun je het containerveld leegmaken. Je slaat het pad naar het document op zodat je dat kunt openen via het open url commando

[andries]

inderdaad

 

het bestand staat fysiek op een server, en kan dus geopend worden. FileMaker slaat enkel een referentie naar dit bestand op. Nadien moet dus niet meer worden geherimporteerd.

 

@ari het kan trouwens ook via send event

 

@ari: voor je mails zit vooral de moeilijkheid in je mails in FileMaker krijgen, eenmaal je daar bent zou je alles moeten kunnen doen... hier zal je toch een plugin voor moeten hebben. Als je een avonturier bent, probeer ScriptMaster en ontwikkel zelf je IMAP script in Java, of er bestaan ook kant en klare plugins die dit voor je doen.

[Ari]

Send event werkt inderdaad ook maar helaas niet altijd (althans bij mijn klanten). Daarom pas ik altijd open URL toe.

 

De plugins die ik ken voor het importeren van mail zijn het wat mij betreft net niet. Met name de afhandeling van bijlagen is niet wat ik voor ogen heb. Misschien iets als gezamenlijk project voor een aantal forumleden?

[andries]

ik vrees hiervoor want dat is vaak zo specifiek per IMAP server (als de mail server al IMAP ondersteunt)...

 

Hier kan je wel een aanzet vinden om dit te verwezenlijken:

http://java.sun.com/products/javamail/javadocs/com/sun/mail/imap/package-summary.html

 

Als je natuurlijk voor de java oplossing wil gaan, je kan ook gewoon in PHP scriptjes schrijven en die op een webserver hosten.

 

Maar het is me ook niet helemaal duidelijk wat je wil. Drag and drop vanuit je mail applicatie of effectief mails inladen in FileMaker.