Web-detectie

[hbrendel]

In FM11 had ik een oplossing: Het bestand werd geopend op een layout waar geen objecten aanwezig waren, die contact maakten met een gehoste database. Er werd geen fout gegenereerd. Daarna deed ik een Set Field in de gehoste database. Wanneer daarbij een fout optrad was de user kennelijk niet online en dan kon ik de user de keus geven om off-line te werken.

 

Nu in FM12 wordt de als externe bron aangewezen file direct herkend als niet aanwezig. Nog voordat er enig venster is geopend staat de gehate foutmelding al op het scherm. Die moet ik bevestigen, vervolgens komt het scherm waarin de user het bestand kan zoeken. Dat moet hij cancelen, maar krijg hem maar eens zover, hij zit in verwarring naar zijn scherm te kijken.

 

Hoe kan ik op een user-vriendelijke manier detecteren of er contact is met de server?

[andries]

contact met de server of gewoon online? als je gewoon online wil testen kan je dit met een webviewer doen, en zien wat de content is

[hbrendel]

Server.

 

Maar ik wil juist het probleem tackelen dat FileMaker 12 begint met een foutmelding voordat er iets anders mogelijk is. In 11 gebeurde dat pas als de database daadwerkelijk iets wilde ophalen uit de remote database. Dat kon je dus voorblijven.

[andries]

ik moet eerlijk toegeven dat ik dat nooit in 11 heb opgemerkt

 

ga er is over nadenken

[Infomatics]

Blijkbaar gebruik je het separatie model. Het enige wat ik kan bedenken is een aparte file die het systeem opstart, zonder connecties naar de server, maar

die een script op de server aanroept, wat een response moet geven, zoiets als.

 

perform script[server ping; scriptparameter UUID]

 

en op de server het script

server ping:

exit script [Get ( ScriptParameter )]

 

waarna je in het startscript kunt controleren of het server script de UDID heeft terug gegeven. als dat het geval is, kan het UI bestand worden opgestart.

 

Is dat wat?

 

Groet,

 

Ruben

[hbrendel]

Een goed idee. Ik ga er eens mee stoeien Ruben, bedankt.

[andries]

ik weet niet of je een script kan aanroepen zonder naar het bestand te verwijzen. je moet dan toch het bestand toevoegen als externe databron?

[Felix]

.

4 oktober 2015 aangepast door Gast

[menno]

Je zou ook gewoon een xml-pagina op kunnen vragen van een tabel die je speciaal voor dat doel toegankelijk maakt. De fmserver-sample DB kan je even gebruiken om testen hoe dat werkt:

http:///fmi/xml/fmresultset.xml?-db=fmserver_sample&-lay=Startup&-findall
of
http:///fmi/xml/FMPXMLRESULT.xml?-db=fmserver_sample&-lay=Startup&-findall

[Felix]

.

4 oktober 2015 aangepast door Gast

[andries]

@Felix, custom webpublishing via XML zal blijven bestaan, en is FileMaker Server gewoon, de XSLT transformaties zijn inderdaad obsolete (jammer genoeg )

[Felix]

.

4 oktober 2015 aangepast door Gast

[menno]

Ik merk dat het best handig is om de documentatie even na te lezen want daarin vond ik:

http:///fmi/xml/fmresultset.xml?-dbnames

Dan krijg je een opsomming van db's die toegankelijk zijn met xml-cwp

die documentatie kan je vinden op je eigen server door te gaan naar:

http://:16000/docs/English/fms12_cwp_xml_en.pdf

[hbrendel]

Jullie geven hier allemaal methodes om te checken of er een internet verbinding is. De titel van deze thread is misschien wel verkeerd gekozen.

 

Ik ben juist op zoek naar een methode die voorkomt dat het gehate venster verschijnt voordat er ook maar iets met de remote database wordt gedaan.

 

In FM11 had ik dit voor elkaar, maar ik kan het niet meer reproduceren in FM12/13.

 

[hbrendel]

Zo, die is groot! Dat komt waarschijnlijk door het retina-scherm.

[Infomatics]

Goedemorgen Henk,

 

Volgens mij werkt mijn methode om te checken of de database te bereiken is, alleen heb je een apart bestand nodig wat dit controleert

voordat het hoofdbestand wordt opgestart omdat het hoofdbestand verwijzingen heeft naar de server.

 

Groet,

 

Ruben

[hbrendel]

Maar dan moet het hoofdbestand alsnog geopend worden, met de mogelijkheid om offline te kunnen werken. Dan komt die error, ook al ga ik direct naar een layout met een TO die lokaal is (zijn).

[Infomatics]

Aangezien het hoofdbestand To's heeft naar de server zal je altijd die melding krijgen.

 

De enige optie is om de offline acties geheel separaat te houden van het hoofdbestand, dus in een aparte file. Je zou het controle bestand kunnen gebruiken

om offline acties te doen en die te importeren in het hoofdbestand als de server weer online is.

 

E.e.a. maakt het systeem wel complexer . . .

 

Groet,

 

Ruben

[hbrendel]

Het merkwaardige is - zoals ik al eerder meldde - dat ik in FM11 ooit een systeem heb gemaakt waarin het wel werkte: geen melding zolang er geen acties waren die de externe database aanriepen. Het rare is, dat ik niet meer kan achterhalen waardoor dit komt. Het bewuste bestand werkt nog steeds, maar ik kan het gewenste gedrag niet meer in een nieuwe toepassing reproduceren, ook niet in FM11.

[Joris Aarts]

Dag Henk,

 

Het werkt wel als je in de bestandsopties een opstartlayout opgeeft die op geen enkele manier verwijst naar je server-TO's. Een opstartscript met 'ga naar layout' is niet voldoende want FileMaker start stiekum toch met de layout die je laatst op een lokale kopie bewerkte.

Probeer het maar: doe op een lokale kopie een bewerking op de layout die géén externe verwijzing heeft en sla die bewerking op. Nu heb je zelfs geen opstartlayout meer nodig! Maar het is wel zo veilig natuurlijk

 

Groetjes,

Joris

[hbrendel]

@Joris: Dit idee pas ik al toe, maar het werkt niet (meer). Ik heb ook al geëxperimenteerd met een leeg custom-menu, gesloten status-area, layouts niet tonen in het menu en een user die niks mag.

 

Wanneer ik het bestand open met debugging aan, dan zie je dat de melding verschijnt voordat er ook maar een scriptstap in beeld verschijnt, noch enig venster wordt geopend. Het enige dat vóór de melding uitgaat is het inlogscherm.

 

Heb jij dit ergens werkend?

[Joris Aarts]

Ja het werkt bij mij in FileMaker 12. Net nog eens getest met een scriptje dat vanop de offline-TO layout een set field doet in een externe TO via een cartesian join. Als je de foutafvanging aan zet dan krijg je geen FileMaker foutmelding maar netjes je eigen scripted boodschap. Ik voeg enkele screenshots toe.

[Joris Aarts]

Het enige dat ik kan bedenken is dat de layout die jij kiest als opstartlayout toch op één of andere manier naar een externe TO verwijst: via een object of via conditional formatting…

[hbrendel]

Ik zal er nog eens goed naar kijken.

[hbrendel]

Het raadsel is niet opgelost, maar het probleem wel.

Ik zal het uitleggen wanneer de NDA afgelopen is.

[Felix]

@TS, Met je laatste opmerking werp je alleen maar een nieuwe raadsel op

@Joris, ook wanneer je opstart met een volkomen lege layout krijg je eerst de gehate foutmelding.

 

Het probleem is dat bij openen FM naar de allereerst in de DB aangemaakte layout springt. Wanneer daar objecten uit gerelateerde bestanden op staan krijg je die foutmelding. Zorg je ervoor dat die allereerste layout geen gerelateerde gegevens hoeft te tonen dan werkt het als onder FM11.

 

Dit lijkt dus een foutje (of veranderde procedure) in het afsluiten/openen van een DB onder FM12. Het maakt niet uit onder welke layout je afsluit; wanneer de DB geopend wordt, wordt automatisch naar de eerste layout gesprongen en wordt geprobeerd alle gegevens op te halen om die te kunnen presenteren. Daarna wordt pas het open script opgestart en gekeken op welke layout er is afgesloten of waarnaar geswitched moet worden. Het kwaad is dan al geschiedt.

 

De oplossing is om bij de file options op te geven naar welke layout FM bij openen moet springen. Kies je hier een layout zonder gerelateerde gegevens dan gaat het wel goed.

 

En dit allemaal zonder NDA Dus de update of FM13 (wil ik wel een versie 13??) gaat dit gedrag weer wijzigen volgens de TS??