Remote importeren van een found set lukt niet

[AvD]

Zodra ik remote ingelogd ben op een databank gehost in de States, open ik één van de tabellen en zoek daar één specifieke record. Daarna moet die record gearchiveerd worden in een andere tabel van dezelfde file. Ik open daartoe op dezelfde server in hetzelfde bestand de gewenste archieftabel en importeer dan die éne record van de found set, tenminste dat is de bedoeling. Maar wat blijkt? Er komen er duizenden binnen: de hele tabel! FileMaker gaat er blijkbaar van uit dat ik een nieuwe sessie start met het importeren en beschouwt de brondatabank dan als gesloten, waardoor de hele inhoud geïmporteerd wordt. In de scriptstap Import Records moet je de file aangeven van waaruit geïmporteerd moet worden. Maar ik zie nergens hoe ik kan aangeven dat niet opnieuw remote moet geopend worden, en een relatief of absoluut pad opgeven gaat niet omdat het bestand nu eenmaal niet hier lokaal staat maar op die server.

[tackenco]

Volgens mij komt dat omdat je in fm meerdere vensters en dus layouts met verschillende resultaten uit eenzelfde tabel kunt tonen. Bij het importeren is het niet duidelijk dat het dan om die specifieke layout gaat waar die ene record staat die gevonden is.

 

Misschien is het mogelijk om een import script te maken waar je eerst de zoekopdracht uitvoert op een bepaalde layout in het remote bestand (met een file referentie) en dan met dezelfde referentie de import uit te voeren.

 

Wat in ieder geval lukt is als je het record exporteert naar een temp file en dan dat temp file importeert.

 

Ben benieuwd naar je definitieve oplossing.

[AvD]

Even een reactie op de suggestie van Tackenco: er is maar één venster in gebruik, en alle layouts van die tabel zijn gebaseerd op dezelfde TOC; ze tonen dus allemaal een found set van één record. Dat is dus niet het probleem. Ik vrees dat de oorzaak zit in het feit dat het importeren loopt volgens een paddefinitie die FileMaker ertoe aanzet dat bestand opnieuw te openen vanaf de server. Ik zou willen dat ik kon importeren vanuit de lokale RAM-versie van het bestand, dus zoals het op de guest computer draait. Maar daarvoor is geen padsyntaxis beschikbaar.

[tackenco]

dan blijft export naar temp file en import de enige optie. Of je moet met een relatie in combinatie met set fields gaan werken.

[AvD]

dan blijft export naar temp file en import de enige optie

Meen je dat nu echt? Het is toch al te onwaarschijnlijk dat zo'n basale functie niet zou voorzien zijn. Maar ik vrees dat je gelijk kan hebben: zelfs een telefoontje naar Yucatán bracht geen soelaas...

[JeanWM]

Dat is de work around die wij finaal ooit ook hebben gebruikt.

 

Het geheel effe local zetten en ons ding doen.

 

Wij hadden wel het voordeel dat 'remote' een ander gebouw op de campus was.....

 

 

Of een scriptje lanceren dat de found set even opslaat als csv of tsv en dat binnenhalen....

[fmwebshop]

Als het om één of weinig record(s) per keer gaat zou je ook veld(en) instellen kunnen gebruiken...

Of veld instel gecombineerd met opzoek functie.

 

Scheelt een hoop rompslomp.

 

Groet

Harry

[tackenco]

Scheelt een hoop rompslomp.

Als het steeds om één record gaat met weinig velden misschien wel maar de export import d.m.v. een temp file is ook zeer eenvoudig hoor. Je bewaart het als fp7 of xsl file en importeert op basis van veldnamen. één keer instellen en klaar is kees (of niels zoals ik ).

Het is toch al te onwaarschijnlijk dat zo'n basale functie niet zou voorzien zijn

Daar kan ik het alleen maar met je eens zijn!

 

Heb je ook nog gekeken naar de optie om d.m.v. een relatie aan te leggen met de tabel waar de records naar toe moeten. Als je dan door je zoekresultaat loopt kan je op basis van die relatie steeds een record aan laten maken in de gerelateerde tabel. Als je in die tabel de velden voorziet van een lookup op basis van diezelfde relatie komt alle informatie netjes over. Je maakt dan wel gebruik van een loop wat soms ook erg traag kan zijn dus in het geval van veel records zou ik toch voor de export import functie gaan denk ik.

 

Groet Niels

[tackenco]

Ik had nog wat gevonden over deze issue, check eens of dit de oplossing is.

http://filemaker.custhelp.com/app/answers/detail/a_id/325/related/1/~/import

het gaat over fm 7 maar wellicht is dit nog steeds van toepassing

[Jeroen Aarts]

Ik had nog wat gevonden over deze issue, check eens of dit de oplossing is.

http://filemaker.custhelp.com/app/answe ... 1/~/import

het gaat over fm 7 maar wellicht is dit nog steeds van toepassing

Ik vermoed dat dit de oorzaak van het probleem is. Ikzelf heb al vaak en probleemloos de techniek van import van een welbepaalde found set in tabellen in dezelfde file gebruikt, bv om te archiveren, of om een tijdelijk tabel dynamisch te vullen in een mailingsysteem.

 

- Jeroen

[AvD]

Dank, iedereen, voor de suggesties en de hulp. Van Jeroen zou ik graag weten of zijn vermoeden bevestigd wordt door het feit dat het importeren hier scriptmatig gebeurt via Open remote langs fmnet en het IP-adres van de server, terwijl het openen van de databank vaak (maar niet altijd) verloopt via Open Recent.

[Jeroen Aarts]

Dank, iedereen, voor de suggesties en de hulp. Van Jeroen zou ik graag weten of zijn vermoeden bevestigd wordt door het feit dat het importeren hier scriptmatig gebeurt via Open remote langs fmnet en het IP-adres van de server, terwijl het openen van de databank vaak (maar niet altijd) verloopt via Open Recent.

Ja, inderdaad, dat is wat het artikel suggereert. Je opent bv. de databank via Favorieten of Open Recent via de hostname (bv. fm-server.domein.com) en in je verwijzing naar het te importeren bestand verwijs je naar dezelfde file, maar dan via IP adres. Je kan het testen door in beide gevallen consequent ofwel ip adres, ofwel hostname te gebruiken.

 

Jeroen

[Jeroen Aarts]

Als het dezelfde file is, waarom gebruik je dan niet gewoon 'file:' in je file reference in je Import script step?

[AvD]

Als het dezelfde file is, waarom gebruik je dan niet gewoon 'file:' in je file reference in je Import script step?

Ja, Jeroen, dat is precies wat er staat, omdat ik dacht dat FileMaker dan excentrisch zoekend meteen zo dicht mogelijk "bij huis" zou beginnen in zijn zoektocht, tenminste dat zegt ie toch zelf in dat dialoogpaneel. Maar dat blijkt dus even anders te zijn...

Toch ga ik nog even experimenteren met alle mogelijke combinaties. Ik hou jullie op de hoogte.

[AvD]

Experiment mislukt: ik log in met Open remote en IP-adres en refereer ook daarnaar in het Import-script. Maar weer krijg ik alle records in plaats van dat ene van de found set. Ik heb ook de zuivere file reference toegevoegd, zoals Jeroen suggereerde. Maar dat geeft me precies hetzelfde resultaat.

Ik vrees dat het een ratelende batterij Set Fields gaat worden, desnoods via variabelen. Dat zal minder energie kosten dan het definiëren van een aantal lookups om de hele santenkraam naar binnen te halen via de relationele weg. Nog een geluk dat ik vorig jaar geleerd heb geduldig te aanvaarden!

[tackenco]

Nog een geluk dat ik vorig jaar geleerd heb geduldig te aanvaarden!

Gewoon rustig blijven ademhalen

 

Ik begrijp dat het om behoorlijk wat velden gaat. Is het dan niet handiger om een export te maken naar het temp pad en deze dan te importeren in de tabel van bestemming? Je bent dan in ieder geval sneller klaar en het is toch een vrij lichte oplossing.

[AvD]

Is het dan niet handiger om een export te maken naar het temp pad en deze dan te importeren in de tabel van bestemming? Je bent dan in ieder geval sneller klaar en het is toch een vrij lichte oplossing.

 

Dat is inderdaad een goed idee, maar het maakt me wat bang: buiten de hoofdgebruikers en ikzelf werkt niemand van alle werknemers daar een binnen een "gewone" FileMaker deployment: alles loopt niet eens via Citrix maar via 2X (spreek uit: toe-iks) en ik vraag me af hoe ik in zo'n omgeving veilig dat temporary path kan definiëren. Maar ik wil het wel proberen. Hier zal het dan wel werken, maar bij die 2X'ers? Wat denk je?

[tackenco]

de get temppath functie geeft toch het pad naar de locale temp folder? Dat zou altijd wel moeten werken lijkt mij. Ik heb wel eens wat gelezen over dat de files in de tempfolder blijven staan ook na het afsluiten van FM dus voor het opslaan gebruik ik altijd een zelfde naam zodat het files steeds overschreven wordt.

[Jeroen Aarts]

Mja, met Set Field ben je natuurlijk zeker. Toch wel gek, want ik heb het probleem proberen te reproduceren vanop afstand op een test fm server, met de bedoeling met opzet dezelfde file op verschillende wijzen te referencen (als dat tenminste een werkwoord is). Maar wat ik ook probeer, FileMaker doet het altijd goed! Getest in FMPro Advanced 10 en FMS 10.

 

Over welke versies gaat het eigenlijk?

 

- Jeroen

[AvD]

Deze klant werkt nog met de negen. Hij heeft zijn eigen server. Zijn werknemers loggen in via 2X, ik op de klassieke manier. Zou er een verschil in behaviour zijn tussen de negen en de latere versies? De nieuwe manier van importeren is ook niet zo oud (vanaf de acht of de zeven?).

[tackenco]

Ben nog steeds aan het zoeken hoor. Ik vond dit in een fixlist:

1.4.6. An Import Records script step can now correctly import a found set of records from a target file that is opened remotely. Specifying a relative file reference to a remotely opened file also works correctly in this case

Wat volgens mij zegt dat volgend FIlemaker het probleem wel bestaan heeft maar opgelost is sinds fm7 v3 (zie: http://www.filemaker.com/support/uplist.html)

 

Wat ik ook nog vond was iemand die het zelfde probleem had maar dat kwam doordat hij meerdere vensters open had van de zelfde applicatie. Ik weet dat ik dit al eerder geopperd had maar wellicht een dubbelcheck dat de applicatie op het moment van importeren niet meerdere vensters heeft openstaan.

 

FileMaker doet het altijd goed! Getest in FMPro Advanced 10 en FMS 10

Dat is de volgende oplossing

 

Groet, Niels