menno

Nee dat is niet correct, alleen in FMS16 was de DataAPI in Beta en deze schakelde vanaf 27 sept 2017 uit. Vanaf FMS17 blijft de DataAPI gewoon werken en kan je gemeten over 12 maanden gemiddeld 2GB per maand per gebruikerslicentie aan data opvragen. Containerdata is van die meting uitgesloten. Dus met een minimaal aantal van 5 licenties kan je per jaar 120GB aan (tekst-)data opvragen. Hoe het precies met een perpetual licentie is geregeld, weet ik niet. Die vorm is echter fors duurder, dus de meeste bedrijven kiezen voor de annual licentie.

Gebruiken jullie en de klanten wel versie 18.0.2 van FM Advanced? In 18.0.1 zaten namelijk inderdaad wat issues met importeren, die ze hebben opgelost. Misschien is de "ongedefiniëerde" import daar ook mee hersteld. De FileMakerDatamigrationTool (FMDMT) vangt eigenlijk alle problemen die je nu noemt op, want daarmee hoef je ook geen imports-scripts te maken. Eventuele serials worden bijvoorbeeld voor je opgehoogd en als je de migratie logt middels een bestandje, dan heb je ook een audittrail van wat de FMDMT heeft gedaan. Na de conversie draairen jullie waarschijnlijk toch een script af om eventuele nieuwe tabellen en kolommen te vullen c.q. te corrigeren en met het gebruik van de FMDMT zal dat niet verschillen. Zie ook hier op het forum:

Als je ook buitenlandse nummers (buiten de BeNeLux) wilt opzoeken, dan kan je ook een koppeling maken met een webservice zoals Phone Format Lookup API van Twilio die is volledig gratis wanneer je alleen het formaat controleert. De techniek is natuurlijk volkomen anders, want je gaat gebruik maken van Insert from URL en de JSON-functies. Hun documentatie is best duidelijk: https://www.twilio.com/docs/lookup/api Hiermee weet je meteen of het geldig nummer is (maar je controleert er niet mee of het bestaat) Een voorbeeldje met Twilio kan je vinden op: FileMakerTips.nl

Ik denk dat de volgende functie doet wat je zoekt: https://www.briandunning.com/cf/1189

Je kan het eens proberen met deze: Let ( [ pnum = Filter ( text ; "1234567890" ) ; type = Case ( PatternCount ( "¶061¶062¶063¶064¶065¶068¶069¶" ; ¶ & Left ( pnum ; 3 ) & ¶ ) ; 6 ; // mobiele nummers PatternCount ( "¶08¶09¶" ; ¶ & Left ( pnum ; 2 ) & ¶ ) ; 8 ; // 08x of 09x zijn tot 12 cijfers lang PatternCount ( "¶010¶013¶014¶015¶020¶023¶024¶026¶030¶033" & "¶035¶036¶038¶040¶043¶044¶045¶046¶050¶053" & "¶055¶058¶070¶071¶073¶074¶075¶076¶078¶079¶" ; ¶ & Left ( pnum ; 3 ) & ¶ ) ; 3 ; // 3 cijfers 010 ... 079 4 ) // overige met 4 cijfers ] ; Case ( type = 8 ; Left ( pnum ; 4 ) & " " & Middle ( pnum ; 5 ; 4 ) & " " & Middle ( pnum ; 9 ; 4 ) ; length ( pnum ) ≠ 10 ; "Lengte is onjuist." ; type = 6 ; Left ( pnum ; 2 ) & " " & Middle ( pnum ; 3 ; 4 ) & " " & Middle ( pnum ; 7 ; 4 ) ; type = 3 ; Left ( pnum ; 3 ) & " " & Middle ( pnum ; 4 ; 3 ) & " " & Middle ( pnum ; 7 ; 4 ) ; type = 4 ; Left ( pnum ; 4 ) & " " & Middle ( pnum ; 5 ; 3 ) & " " & Middle ( pnum ; 8 ; 3 ) ) ) Hij werkt denk ik voor de meeste gewone telefoonnummers, maar voor de "niet geografische nummers" niet. Wanneer je die wel gebruikt, zal je die eerst nog even moeten checken en de formule daarop moeten aanpassen. Zie daarvoor deze wikipedia-pagina met wat meer info. Een hele andere methode heb ik beschreven op FileMakerTips, dat werkt met een tabelletje en maskers die je opgeeft.

Dan kan je niks anders dan die timestamp eerst in een tekstveld importeren en dan met een berekening omzetten naar een timestamp

Als je uit een filemaker-bestand een timestamp-veld importeert in een timestamp-veld in jouw bestand, dan hoef je niks ander te doen dan 6 uur op te tellen bij de waarde die je importeert.

Nee, als je veldnamen aanvinkt, dan gaat FileMaker de veldnamen van de eerst rij met gegevens uit Excel matchen aan de identieke veldnamen in FileMaker. Als de veldnamen niet overeenkomen, dan wordt er in die velden niks geïmporteerd. Jij moet eigen importvolgorde c.q. laatste volgorde gebruiken. FileMaker vindt veldnamen met - tekens niet leuk zodat die veldnamen in berekeningen als ${veld-naam} moeten worden geschreven en anders vervang je de - voor een _. Het laatste heb jij gedaan, maar dan werkt de "veldnamen" import dus niet meer.

Als je de eerste regel van de excel wel importeert, dan komen altijd dezelfde waarden (veldnamen van de excel) in de dezelfde aangewezen velden in FM terecht wanneer de importvolgorde niet is gewijzigd. Je kan dat gegeven controleren en als die waarden dezelfde zijn als altijd, dan kan je dat overbodige record weggooien. Klopt het niet, dan zou je alle geïmporteerde records kunnen wissen (is ook maar een suggestie).

Ja dat is duidelijk en nu hebben we ook alle info. Verander je de structuur van de FileMaker DB weleens, als in verwijder je wel een kolommen (velden)? Ik zie namelijk achter "shipping-addressid" in FM een lege plek staan. In het verleden was FileMaker niet erg goed bestand tegen het verwijderen van velden. Als je dat in een bepaalde tabel had gedaan, dan was vaak een importvolgorde in die tabel ook meteen gemold. Velden toevoegen was meestal geen probleem, tenzij er spontaan bij imports data in terecht kwam die er niet in hoorde. Wat je nog zou kunnen proberen: 1) De eerste rij tóch gewoon importeren en die na de import verwijderen... je zou die regel kunnen gebruiken om te controleren of de importvolgorde nog wel correct is. De wijze waarop je nu de import hebt gedefinieerd is namelijk "statisch" en wordt simpelweg op de kolomvolgorde uitgevoerd. 2) Proberen de import vanuit een lokaal excel-bestand te definiëren en kijken of die wél wordt vastgehouden. Als dat lukt, dan wijzig je het pad weer naar het netwerkpad en kijk je of het nog lukt. Je moet ter controle wel even FileMaker bij iedere controle opnieuw opstarten om te voorkomen dat er iets uit de cache vandan komt. Imports over het netwerk zijn bij mij ook wisselend succesvol, dus het kan zijn dat je eerst het importbestand lokaal moet halen en dan de import moet uitvoeren.

Je importeert iets uit een testbestand, daarna open je een bestaand of nieuw scipt en je voegt daar een nieuwe regel toe "Importeer records". Als je dan "Specify import order" of "importeervolgorde opslaan" aanvinkt, dan is de laatstgebruikte importvolgorde daadwerkelijk opgeslagen en wordt hij de volgende keer weer gebruikt.

Zoals bijvoorbeeld:

Importeren is iets wat de meesten hier "dagelijks" doen en maken. Dus in jouw situatie is er iets wat het proces verstoort of je doet gewoon iets verkeerd. Het probleem is alleen dat wij tot nu toe van jou niet het complete plaatje krijgen en wij dus aannames moeten doen. Dus zal je jouw situatie een beetje beter moeten beschrijven: Welk Operating System van de computer met FileMaker? En welk OS draait er op de bestands-server? Hoe ziet je bestandspad eruit? Gebruik je file:/filemac: of filewin: aan het begin van je pad? Is de importvolgorde daadwerkelijk vastgezet, m.a.w. staat het vinkje bij de importvolgorde aan? Gebruik je het het FM-bestand lokaal of geshared vanaf een FMServer? Welke excel-versie is de bestandsstructuur? Soms vertellen screenshots ook heel veel en die kan je gewoon in de teksten plakken die je hier schrijft

Wel een ander eindpunt, maar als het goed is wel. Heb dat zelf niet getest

Misschien is dit iets voor jou of je klant. Dit voorbeeldje doet alleen platte tekst uit normale pdf-bestanden halen, maar met dezelfde api kan je ook tekst uit gescande documenten halen. Het is niet gratis, maar je hebt geen plugins nodig. Zoals je in het voorbeeld zal zien stelt het qua scripting ook helemaal niks voor. ConvertApi_PDF.fmp12