Updaten van record met gerelateerde velden

[BasB]

Daar gaan we dan.

 

Ik ben een webinterface aan het maken voor een database die gemaakt is door een klant. In de database zitten letwel 130 gerelateerde velden die allemaal via het web geupdate moeten kunnen worden.

 

Echter lijkt dit met een normale -edit query niet te werken. De data in de gerelateerde velden wordt wel netjes getoond, maar het wegschrijven wil niet lukken.

 

Zit er nou niets anders op dan 130 calculatievelden te maken!?

 

groeten,

BeeB

[BasB]

En de oplossing gevonden op blueworld. Schijnbaar de enige site waar je de minpuntjes van FileMaker kan vinden.

 

just wanted to let you know, my related field/editing problem was due to

a change in the CDML code for 5.0. Just wanted to make you guys aware if

you are converting CDML over from 4.

 

When specifying a related field, you will now need to specify which

portal row you are editing - relationship::field.portalrownumber.

 

in mijn geval dus 130 portaaljes van 1 regel.

 

groeten,

BeeB

[Koen Van Hulle]

Je kunt natuurlijk ook rechtstreeks de gerelateerde databank editeren i.p.v een portal te gebruiken.

 

Koen

[BasB]

Dat had gekund. Ware het niet dat elk veld over zijn eigen relatie gaat. 130 relaties voor 130 velden, 130 records in het relatiebestand

[Peter Wagemans]

En wat doe je dan als je 2 portaalrijen tegelijkertijd wil aanpassen?

En hoe deed je het vroeger toen CDML niet naar de portal rij vroeg?

 

Ik heb ergens een stukje code liggen dat een "portal-submit" aankan, ttz de portal als 1 form beschouwd, en de gerelateerde records correct aanpast.

Kan het wel eens opzoeken iemand dat wil, maar dat is misschien niet nodig als er een antwoord is op bovenstaande vragen. Ik stel mij voor dat de code aanpassing nodig was om de dingen correcter te doen gebeuren.

 

Gezien BlueWorld zelf Web Companion heeft geschreven voor FileMaker, is het ook aan hun om de bugs er uit te halen. Ze zijn immers grotendeels op Web Companion aangewezen om grote broer Lasso te doen werken.

[BasB]

Het aanpassen van 2 protaalrijen tegelijk gebeurt nooit omdat elk portaal max. 1 rij bevat. (Ja ik heb de Db's ook niet ontwikkeld).

 

Ik zou ff in vorige projecten moeten kijken of ik daar gerelateerde velden in wijzig, maar deze "ongedocumenteerde wijziging" schijnt er pas vanaf een verie 5.x in te zitten.

 

Ik gellof ook niet dat ik ooit in het verleden meerdere gerelateerde records tegelijk heb hoeven wijzigen. Vaker was het, zoeken -> lijstje -> detail -> edit -> bewaar

 

Dat stukje code is altijd interessant om te bestuderen.

[Peter Wagemans]

Het was gedocumenteerd toen de 5.0v6 web companion uitkwam. Die hebben we bij ons nooit geimplementeerd omdat die versie geen shortcuts in de web folder meer ondersteunde. FileMaker fixte dus de ene bug terwijl ze er andere bugs bijstopten, dat doet je wel even nadenken over het zomaar toepassen van maintenance updates.

We zagen het gelukkig direct omdat er plotseling toen zo'n 50 web sites niet meer werkten...

 

Web Companion kan sinds 5.0 specifieke portaalrijen wijzigen, maar de "submit" wijzigt maar 1 portaalrij. Wat we deden voor een bepaalde site, was 1 form maken waar alle portaalrijen in zaten. In ons geval was het een form waar de browser een checkbox al of niet moest aanzetten voor een bepaalde portaalrij. Wat we deden was met de javascript "On Submit" functie werken. Die rijgde aan een string een "0" als de checkbox niet aangeduid was, en een "1" als de checkbox wel aangeduid was.

We submitten dus een string "00110110011111..." naar de web host, die met een -script parameter door de portal records liep en alle checboxen aan de hand van deze controle string aanpaste.

Kermit weet er ook alles van, want we hebben die site samen in mekaar gebokst.

[BasB]

Dat idee heb ik ook altijd als ik mijn fiets bij de fietsenmaker breng.

Hij repareert de band maar sloopt de lamp.

 

Het is een mooi truukje om een string te maken, maar kan FM dat wel aan als meerdere mensen zo'n request tegelijkertijd doen?

[Koen Van Hulle]

Dit is geen probleem. FileMaker behandelt 1 request per keer. Dus pas als het script is uitgevoerd, zal de andere gebruiker met het script kunnen beginnen. De gebruikers staan als het ware in een wachtrij.

 

Koen

[BasB]

Dan moet je de scripts dus niet al te ingewikkeld maken. Zeker als je een site hebt waar meer dan 1000 hits per dag op vallen.

 

Maar voor dit script zal dat niet het geval zijn.

[bram]

Ik denk dat de zekerste oplossing is om te werken rechtstreeks in de database.

Dat zou je kunnen doen met inlines.

Een nadeel is, dat dit niet al te snel zal werken, omdat je 130 keer moet "inline-en"

[Koen Van Hulle]

Ik moet zeggen, we zijn hier met de eerste testen van FileMaker 6 bezig en kunnen wel zeggen dat web companion 2x sneller is geworden.

 

 

Koen

[bram]

2x Sneller... ik wil niet al te pessimistisch doen, maar geef toe dat het nog niet wereldschokkend is.