Marsau

Beste mensen, Een terugkerend onderwerp... Dat m.i. aan belang wint als je systemen 'socialer' wilt ontwikkelen... Ik zoek een charmante mogelijkheid om de gebruikers een (zo veel mogelijk) realtime overzicht te tonen van de alle ingelogde gebruikers. Dit moet de samenwerking ten goede komen, en ook nieuwe functionaliteit mogelijk maken. Standaard is het in Filemaker niet mogelijk om per file een gebruikerslijst te tonen, maar met het nieuwe data API zie ik wel mogelijkheden (maar heb nog niet doorgrond hoe precies...) Ik heb eerder dit eerder geprobeerd te realiseren met 'sessie'-records, waarbij elke gebruiker een record krijgt bij inloggen, te verwijderen bij uitloggen of server side opschonen na een periode van inactiviteit. Werkt wel, maar omslachtig en nooit helemaal accuraat. En verre van charmant. Welke benaderingen passen jullie toe, of wat denken jullie ervan?

Ik vind het een fascinerende oplossing, Hans Erik. Ik weet alleen niet of je werkelijk krijgt - of kunt destilleren - wat ik bedoel: een lijst van actieve gebruikers.

Inderdaad, je moet een soort server-side opruimscript hebben dat 'oude' kaarten verwijderd - en wat is dan 'oud'? Bovendien is inactiviteit niet per se absentie, dus per ongeluk zou zo'n sessie-record onterecht verwijderd kunnen worden. Ik heb het redelijk werkend, maar accuraat is anders. Het idee van sessiekaarten dient overigens ook een ander doel. Een persoonlijke sessierecord kan je een 'Algemeen' tabel hanteren met alleen maar velden tbc interface, zonder risico op record-locking, gevaar van verwijdering etc. Een meer accurate oplossing - althans voordat Filemaker deze functionaliteit zelf ooit gaat verzorgen - is de Admin API. Met hulp van Menno heb ik een paar oplossingsrichtingen kunnen verkennen. Je kan (per bestand) een user- en/of accountlist genereren, en dat zelfs als een tabel in het systeem verankeren. Een serverside script (om de 60 of 120 sec) houdt alles synchroon. Kijk er al een weekje naar, en het werkt vlekkeloos.

De tool is onmisbaar als je ook gebruikers wilt migreren. Er is behoorlijk wat intelligentie ingebouwd voor wat betreft matchen van velden e.d. Commandline interface is wellicht intimiderend. Migratie gaat overigens razendsnel. In ieder geval zijn er mooie tools gemaakt om het gebruik ervan te vereenvoudigen, bijvoorbeeld die van Soliant. https://www.soliantconsulting.com/labs/filemaker-17-data-migration-tool-demo

Je kan wat meer controle krijgen door een scripttrigger te gebruiken. Bij vastleggen van het het betreffende veld laat je dan een script een timestamp vastleggen. Je kan dat afhankelijk maken van de gebruiker. Je kan zo ook een changelog bijhouden, een must bij bepaalde toepassingen.

Dank je wel. Ik kende deze al, maar was eigenlijk benieuwd naar verdere toepassing. Of wellicht andere benaderingen.

Hi Menno, Wat ik heb gezien.. Bijvoorbeeld: 24llxb levert een foutief resultaat: 24-LLX-B Een reeks van vier letters zou moeten leiden tot twee gelijke paren: 24-LL-XB Ik dacht dat dit kwam omdat je in de recursie slechts steeds checkt of er een wisseling cijfer/letter of letter/cijfer plaatsvindt, maar er speelt een dus nog een conditie. RMW heeft dat uitgekauwd in zijn formule.

Hoeft niet, hoor... Je kan die gerelateerde informatie gewoon in de werkbon brengen.

Deze recursieve CF gaat mis bij een reeks van 4 letters of cijfers. De eerste formulering van RMW werkt volgens mij wel. Goede suggestie om even te filteren op getallen en hoofdletters.

Moet dat geen 12.00 uur zijn? Anders geformuleerd (ik denk dat je hetzelfde bedoelt..): indien T1 < T2, dan T2 - T1; indien T1 > T2, dan wordt de datum overschreden, en bereken je T2 - T1 + 24. 4 - 16 + 24 = 12 De timestamp benadering kan handig zijn als einddatum niet per se de volgende dag is, maar mogelijk nog later... Timestamp reken je uit door combinatie datum en tijd. Timestamps zijn ook handig als er meerdere tijdsberekeningen uitgevoerd moet worden. Bijvoorbeeld bij verschillende tarieven per tijdsvak.

In principe zo eenvoudig dat het de moeite van een opzetje niet waard is, maar de complexiteit zit in de finetuning: toepassing van bibliografische conventies, hoe om te gaan met uitgaven met meerdere auteurs, meerdelige uitgaven, toepassen van tag/trefwoorden systeem voor meta-informatie, digitale en/of fysieke uitgaven, etc. Dat is behoorlijk maatwerk en afhankelijk van je doel/wensen.

Cryptisch probleem. Ik weet dat de syntax met FMS17 iets is gewijzigd ten opzichte van de voorgaande versies. Maar kan geen fout in jouw URL vinden. Probeer het eens zonder de home-url.

Of gebruik timestamps: geen enkel probleem om hiermee te calculeren. Je dekt dan ook de eventualiteit af dat je over twee dagen plannen.

Nog wat input... Als het je niet gaat om de verhuur van kisten, maar simpelweg om het beheren van 'verpakkingsmateriaal' (toewijzing, beschikbaarheid etc) dan kan je m.i. wel vasthouden aan een kisten-tabel. Bij elke verhuur-regel (artikel x project) neem je een verwijzing op naar een toegewezen kist. De kisten die zijn opgenomen bij de actieve verhuurregels zijn niet beschikbaar. Daar kan je een valuelist op bouwen als je nieuwe projecten aanmaakt. Op het moment dat je vastlegt (opmaak contract?) verdwijnen die kisten uit de lijst van beschikbare kisten. In het kisten overzicht kan je direct zichtbaar maken welke kisten beschikbaar en welke in gebruik zijn (samen met een verwijzing naar het project/verhuurder). Uiteraard kan je ook zichtbaar maken wat de huidige inhoud is (en gewicht als je wil) en wat de historie is van het gebruik.

Voor zover ik weet heeft dit probleem met clients te maken, ongeacht of het bestand lokaal of via een server geopend wordt. Check of je werkelijk alle instanties van dat Adobe bestandje verwijderd hebt. Check ook de library van je persoonlijke account.

Het kan een dingetje zijn met de Acrobat plugins. Eerder gehad, er was een quick fix. Kijk eens naar https://community.filemaker.com/thread/175712 of https://community.filemaker.com/thread/181147

Als de file gehost is, check dan even de firewall.

Ben het zeker met je eens dat een correcte, eenduidige invoer veel problemen voorkomt. En is ook een design-opgave. Maar het probleem was hier niet zozeer eenduidige invoer, maar het voorkomen van duplicaten. Autocomplete werkt in de exacte modus. Als je een match hebt, hoef je dus niet verder te gaan met de invoer, maar kan je de betreffende record tonen. Als je geen match hebt, kan je onterecht alsnog invoeren. Een typefout, een zelfde naam maar ander adres, etc.: daar heb je iets aanvullends voor nodig.

Probeer eens met een Mac binnen het netwerk. Dan sluit je mogelijk uit dat Windows het probleem is.

Daar ging deze vraag over. Zorgvuldige data-invoer. Suggestie was om bij invoer alle potentiële duplicaten te laten zien, en dan de gebruiker laten beslissen. Dan moet je 'fuzzy' zoeken was mijn stelling. Jij weerspreekt dit en komt nog steeds niet met een antwoord. Wel met een drogredenering waarvan ik de naam nog niet ken (..terugverwijzen naar het reeds gedeelde, gemeenschappelijke uitgangspunt, maar dan als suggestieve tegenwerping...) Verder visualiseerde ik een oplossing op één scherm. Ik geloof niet dat jij dat eerder deed, maar begrijp dat jij meent van wel. Excuses dat ik je niet alle credits heb gegeven, of dat je dat gevoel hebt, kennelijk belangrijk, maar eerlijk gezegd heb ik dit idee ook als eens uitgewerkt. Moet je ook zeggen dat veel van de kennisuitwisseling in forums gebaseerd moet zijn vrije associatie op elkaars input. Dialoog heet dat dan.

Opmerkelijk dat je twijfelt aan mijn leesvaardigheid, en ook niet zo aardig. Jouw "beschrijving", die ik heb gelezen, gaat niet in op mijn advies voor een fuzzy aanpak. Ben benieuwd waarom jij de exacte benadering voorstaat in dit geval, om mogelijke duplicaten te identificeren. Hier heb je mijn omschrijving kennelijk wel goed gelezen... Wat wil je hier eigenlijk suggereren? Probeer je vrije gedachtenvorming op dit forum een beetje te beteugelen?

Lijkt mij een onzinnige observatie. Dat er specifieke vereisten zijn wil niet zeggen dat je ze niet kunt maken. Papier, UBL of pdf, wat je wil.

Volgens mij kan je wel heel dichtbij komen als je invoerschermpje maakt (of laat maken) zoals ik heb geschetst. Kleine moeite en veel gebruiksgemak. Waterdicht is onmogelijk tenzij je met DNA-profielen gaat werken :mensen maken typefouten, verhuizen, wisselen van mailadres, etc. Door fuzzy mogelijke duplicaten zichtbaar te maken kan je zelf beoordelen of je met echte nieuwe persoon te maken hebt, terwijl eenmalige invoer mogelijk blijft. Succes!

Zie mijn opmerking: hoe exacter je het maakt, des te groter de kans op duplicaat invoer. Gebruik van deze operator "==" ondergraaft dus de kwaliteit van je eigen aanpak. Je moet het juist een beetje fuzzy bepalen bij de namen, en exact op mogelijk andere onderdelen waar de eenduidigheid van invoer groot is, zoals bijvoorbeeld postcode/nr combinatie. Een leuke interface zou zijn dat je bij invoer niet direct een nieuwe record aanmaakt maar in een portaaltje eventuele matchende records ziet passeren, met de mogelijkheid: - deze aan te klikken en daarin verder te werken, - op basis van de invoer direct een nieuwe aan te maken. Sterk is dan ook om te beginnen op eenduidige sleutels: postcode en huisnr... (kan je meteen een adres lookup doen...)

Waterdichte controle is sowieso niet haalbaar: elke typefout zal worden beloond met een nieuwe unieke registratie. Als je deze functionaliteit serieus wilt vormgeven moet je denken aan soort validatiescript dat een mogelijk duplicaat detecteert en presenteert. Met de optie om deze te negeren.