Extern opgeslagen container, update FMP12 bestand gaat fout

[SuperWimmie]

Dag allemaal,

 

Filemaker containers kunnen extern opgeslagen worden.

Ik heb nu een voorbeeld, waar ik PDF bestanden op die manier buiten het FMP12 bestand houdt.

De opslag is onbeveiligd en bevat PNG en PDF bestanden, die als File zijn aangebracht.

 

Zodra ik in een andere versie van mijn programma de tabel ga importeren, ontdek ik bij de import dat één veld fout verloopt, het extern opgeslagen containerveld.

Deze zijn in de nieuwe situatie leeg. Maar ook weer niet allemaal, er zit een JPG bestand in die wel goed verwerkt wordt.

 

Heeft iemand een idee hoe ik de fout kan achterhalen of oplossen?

 

Groeten,

Wim.

[Ari]

Is reeds jaar geleden door mij als bug gemeld aan FM maar blijkbaar nog niet opgelost. Workarounds:

1. Go Supercontainer

2. Doe de containervelden in een apart bestand en neem dit niet mee in de update

[SuperWimmie]

Ik zit al een tijdje te bedenken wat ik er mee moet...

Er is nog optie 3: Bestanden als referentie opslaan.

 

Nummertje 2 van jou is ook het overwegen waard. Dank voor de tip!

[Felix]

.

Edited October 5, 2015 by Guest

[SuperWimmie]

Klopt, Felix.

 

Ik krijg echter elke werkdag zo'n 80 PDF's te verwerken, deze gegevens moeten we jaarlijks bewaren.

De PDF's zijn niet te zwaar, maar de aantallen tikken door.

 

 

Ik heb dan ook voor de gein de containers in de database opgeslagen en de update laten draaien over de nieuwe versie die ze nog extern had staan

Maar ook dat gaat fout.

Reden was de bestandspaden, waar ik in het record een aanmaakdatum heb staan en die weer vertakkingen laat maken in de mapstructuur.

Maar bij de import kreeg de container voorrang op de datum, waardoor deze met waarde 0 is gaan werken.

Na de import waren alle containers alles fout geplaatst...

 

Vooralsnog gaat mijn puntje 3 het worden, dat levert de meest stabiele situatie op.

 

Jammer, want verder werken de externe containers wel lekker!

[rmw]

Mogelijk nog een optie: twee keer importeren.

Eerste keer alle record gegevens (maak nieuwe records)

Tweede keer de container info (updaten van bestaande records obv een sleutel)

 

Dat is voor mij een veel gebruikte methode voor auto-enter waarden.

Bij het importeren van gegevens in velden met een auto-enter, krijgt de auto-enter voorrang boven de aangeboden info.

Door twee keer te importeren kan je dat omzeilen.

Dat lijkt hier ook mogelijk.

 

HTH

 

rmw

[Felix]

.

Edited October 5, 2015 by Guest

[SuperWimmie]

Auto-enter waarden heb ik altijd uit staan bij updates.

En toch krijgen we problemen.

 

Met betrekking tot de 2e importactie: Het is wel een leuk idee, inderdaad.

Een nadeel is dat er dan een relatie komt te liggen met een extern fmp12 bestand, iets dat ik met man en macht probeer te voorkomen.

Ik heb het hier over een standaard programma dat honderden keren uitgezet is, onder Mac en Windows (en iOS).

 

Net even een wandelingetje gedaan en ik liep mij te bedenken of de bestandsnamen ook niet in een tekstveld zijn op te slaan, om na de import de containers opnieuw te vullen vanuit de tekstwaarde.

Als het goed is, staan alle bestanden nog op de juiste plaats (onbeveiligde uitvoering) en zou het daarmee te herstellen zijn.

 

Bij een beveiligde uitvoering kan een oplossing gemaakt worden door ze te exporteren naar een verwijzend bestand en na de conversie weer terug te plaatsen.

Het is daarmee wel een dubbele activiteit omdat je eerst moet exporteren.

 

Met een toename van minstens 80 PDF's per werkdag, hoop ik dat we over twee jaar de update nog in één nachtje voor elkaar kunnen krijgen...

En die 80 per dag... ik hoorde mijn klant iets roepen over "buitenland".

Schijnt nog wat groter te zijn dan "binnenland"...

Bewaarplicht: 7 jaar.

[rmw]

Je kunt de autoenter waarden toch uitzetten bij importeren?

Ja, dat kan.

Maar het is daar alles of niets.

 

Auto-enter van een UUID en van de creation date moet aan, maar auto-enter van btw percentage bij artikel moet uit, want dat staat in het te importeren bestand.

Dat kan alleen worden verholpen door twee keer te importeren.

Eerst met auto-enter aan en aanmaak records.

Vervolgens met auto-enter uit en update obv sleutel.

 

Heel vroeger (FM6) had de waarde uit het bestand voorrang boven de auto-enter, maar dat is helaas niet meer zo.

 

rmw

[rmw]

...

Een nadeel is dat er dan een relatie komt te liggen met een extern fmp12 bestand, iets dat ik met man en macht probeer te voorkomen.

 

Niet als je de bestandsnaam in een variabele stopt en de variabele gebruikt in de import-bestandsverwijzing.

De import bestandsverwijzingen staan los van de external datasources (dat is hier dan weer een voordeel )

 

rmw

[SuperWimmie]

"Import is geen probleem, maar om hem voor de tweede keer er langs te laten lopen, heb je een relatie nodig."

 

... dacht ik net.

Maar nu ik het nog eens lees, hebben we het hier inderdaad over 2 keer importeren. Leuke gedachte!

 

Zou zo maar een oplossing kunnen zijn.

[SuperWimmie]

Hhhmmm.... bij de tweede keer importeren geeft Filemaker weer de volgende fout:

 

Total fields skipped due to errors: 651

 

van de in totaal 680 records.

 

Errorcode 729: Records could not be imported.

Bij de nieuwe import van Records komt hij met dezelfde fout, terwijl de records wel degelijk geplaatst worden.

Slechts het veld met de externe container loopt fout zodra deze gevuld is. De records zonder inhoud in het containerveld zijn precies de aantallen die buiten de error vallen.

[hans erik]

Gaat het alleen bij PDF's fout?

 

En welke PDF reader gebruik je? Preview of Acrobat?

Verder zou ik ook denken aan een probleem met de padnaam voor de externe container.

 

HE

[SuperWimmie]

Gaat ook bij JPG fout.

 

Heeft volgens mij weinig met de reader te maken.

 

De fout zit in het overkopieren van één FMP12 bestand naar een ander FMP12 bestand met een extern opgeslagen container.

 

Alle containers met inhoud, gaan dan fout.

[SuperWimmie]

Ik heb de situatie kunnen maken dat het goed gaat.

 

Mijn oude updateprocedure is dat een Pro of Runtimer een bestandscopy doet naar het buroblad.

Een nieuwe versie mag je overal plaatsen, omdat hij de oude gegevens uit het buroblad haalt en importeert.

Met deze procedure loopt het fout, omdat Filemaker de externe bestanden niet kan vinden en daarmee de import afkeurt.

 

Voor iOS had ik al een andere updateprocedure.

Deze was gebaseerd op het bestand PrintCMR.fmp12 voor de operationele versie, waar ik PrintCMRupdate.fmp12 gebruik voor het importeren uit PrintCMR.fmp12, gevolgd door het "save copy as" die PrintCMRupdate.fmp12 kopieert naar PrintCMR.fmp12.

 

Dezelfde iOS procedure heb ik nu gebruikt voor de Pro versie.

Dat houdt in dat de nieuwe versie van PrintCMR als PrintCMRupdate wordt geplaatst, in dezelfde map.

De verwijzingen naar de extern opgeslagen containervelden is in beide bestanden exact gelijk.

 

De updateprocedure wordt gestart en de kopie-actie loopt vlot.

Na afloop wordt het bestand PrintCMRupdate over die van PrintCMR gekopieert.

Na de start van PrintCMR blijkt alles goed te staan, het werkt.

 

Eén aandachtspunt:

De extern opgeslagen bestanden zijn wel gedupliceerd...

Reden is dat ik veldgegevens gebruik om submappen te maken voor de locatie van externe containervelden.

Filemaker verwerkt eerst de extern opgeslagen containervelden, om daarna pas de overige velden te vullen.

Dit heeft een nieuwe submap opgeleverd, met exact alles er in...

Die map mag direct weer weg.

 

Het is zeker geen strak verhaal, dat Filemaker heeft geleverd.

Er wordt blijkbaar niet vanuit gegaan dat je ontwikkelt op een andere versie dan de operationele.

 

Ingeval van beveiligde externe containervelden, vraag ik mij af hoe Filemaker dit ooit gemakkelijker wil maken...

[Infomatics]

Het is het eenvoudigste om de containers in een aparte database op te slaan. aangezien daar alleen de containers in

cyaan hoeft dit bestand ook niet bijgewerkt te worden bij een nieuwe versie.

 

Groet,

 

Ruben

[SuperWimmie]

Versie 13.0v2 is zojuist uitgebracht, met een update op dit punt.

 

Getest en het lijkt mij geheel opgelost te zijn.

 

Bij de import krijg je dat extra schermpje voor het automatisch bijwerken van alle berekeningen, daar zit een extra keuze bij om de containervelden te behouden.

Indien aangevinkt, kopieert FM de link naar het bestand, zonder het extern opgeslagen bestand verder nog te betrekken in de import.

 

Ik heb de test nogmaals uitgevoerd buiten bereik van de container bestanden, om daarna het nieuwe bestand weer op zijn orginele plaats te kopieren.

Daarna zijn alle links naar de externe bestanden intact gebleven.

 

Ik ben er blij mee