Rony Rabijns

Ik ben er even tussenuit geweest en dan weet je dat dingen veranderen met de tijd. Dit is een vooruitgang. Dank Peter.

ceiling ( totaal_aantal_stickers / aantal_stickers_op_een_vel)

Neen.

Dat klopt ook. Ik heb de vraagsteller enkel op het juiste pad willen zetten. Ik gaf een mogelijke oplossing voor het niet-tonen van records in een layout. Hoe hij nu moet verdergaan, wat hij zal zien, wat hij niet zal zien, wat kan en niet kan, vindt de vraagsteller dan wel in handleiding of via de alom gekende trial-and-error-methode.

Je kan wel dmv privilege-sets zorgen dat records die voldoen aan bepaalde voorwaarden niet getoond en/of gezocht worden.

Koen, Ik heb de updates gedaan, maar het vreemde was/is, dat het probleem plots opgelost was voor de updates geinstalleerd waren. Ik verdenk OS X 10.5 van instabiliteit ...

Ben er een tijdje tussenuit geweest, maar iedereen wordt nog goed verder geholpen zie ik!

Inderdaad via Airport. Maar bijna alle toestellen gaan via Airport. Ik had ook al handmatig een IP-nummer ingesteld. Zonder resultaat. Ik ga het wel even proberen met een UTP-kabel. Dank alvast.

Bij een klant kan ik vanop een MacBook Pro (OS 10.5.x) geen enkel FM-bestand openen dat gehost wordt op een interne FMSA 9-server. Vanop alle andere Macs en Windows-machines wel. Lokale bestanden is geen probleem. Extern gehoste bestanden is ook geen enkel probleem ! IP-range is in orde. Iemand een suggestie?

Ja, dat kan je (althans) op de Mac, aanvinken onderaan je inlogscherm.

Dat doe ik anders. Ik laat ze zoeken/ingeven op een "gepoetst" veld: auto-enter Filter(telefoon;"0123456789") Op die manier kan je het telefoonnummer cijfermatig intikken en moet je niets afweten van formattering of geplogendheden.

Daarom dat ik hierboven ook zei:

Dat is 'm inderdaad. Ik gebruik dat veel en werkt vlekkeloos. Wel goed opletten dat je geen dubbele objectnamen gebruikt.

Sorry, ik kan je hierop niet antwoorden. Ik gebruik Citrix enkel in combinatie met FMS 9. Dan stelt zich dat "probleem" niet.

Bijvoorbeeld de zeer grote snelheidswinst voor de clients die extern aanmelden via Citrix op een FMS. De reden hiervoor is dat er in een Citrix-omgeving uiteindelijk enkel "schermen" over en weer worden gestuurd ipv zeer veel data in geval van een gewone externe FM-client.

Wat wel eens wil helpen, is een startscript maken waarin je "een keer doet alsof". Ik bedoel daarmee dat je het script een aantal maanden vooruit laat lopen en terug achteruit. Dan moet je ook wel wachten natuurlijk maar dan valt het niet zo op voor de gebruiker. Het hoort dan schijnbaar bij het openen van het bestand. Een andere oplossing zou kunnen zijn om alles nog eens goed te overdenken en te kijken of je de kalender wellicht te complex of zelfs op de verkeerde manier hebt opgebouwd.

De berekening niet opslaan. (unstored calculation; indexering uitschakelen bij "storage options", rechts onderaan in het dialoogvenster bij het aanmaken van een berekeningsveld)

Ik begrijp het nog steeds niet. Sorry.

Marco, Ik heb je file bekeken maar de bedoeling ontgaat me een beetje. Je toont bovenaan een portaal met alle records. Onderaan ga je filteren. Dat begrijp ik. Maar waarom wil je in dat filterportaal de gefilterde records zien, en alle andere records die niet gevonden werden (wat jij noemt de "resterende gegevens")... Is dat dan niet hetzelfde als het bovenste portaal ?

Bijvoorbeeld alsvolgt: Door gebruik te maken van de scriptstap ShowCustomDialog(), de input opslaan in globalen, en die dan daarna gebruiken in je Find()-routine.

Er is een documentatie-forum dat hier voor gebruikt kan/mag worden. Om die reden wordt het beheerd door de moderators. Ik zal eens kijken als ik de tijd heb, om wat linken aan te leggen vanuit dat forum naar de voorbeeldfiles. Maar denk er aan, geduld is een mooie deugd ...

Wel opletten met de count(relatie::veld). Count() telt enkel de records waarvan het opgegeven veld ingevuld werd. Daarom is het beter de ID-velden te tellen.

Ik denk dat Troi daar een plugin voor heeft.

Ja dat moet. De software draait bij een aankoopcentrale die haar leden actuele prijzen toelevert. Indien de centrale dat niet automatisch doet, is de kans groot dat de leden de prijzen (zelf) niet of te laat updaten. Dat bleek in het verleden een probleem te zijn. Toen had ik een systeem op poten gezet zoals jij aangaf. Ik stelde vast dat bepaalde leden de prijzen nooit updaten, met alle gevolgen vandien ... Zijn we nu terug bij af wat het probleem en de mogelijke oplossing betreft?

Een server (met een moederbestand) moet in een 40-tal databanken (de dochters, een aantal op haar eigen schijf, een aantal extern buitenshuis) overeenstemmende tabellen van actuele data voorzien. Dat gaat met een script d.m.v. set field()'s waarbij gegevens die bestaan geupdate worden, en gegevens die nog niet bestaan worden toegevoegd. (Ter zijde: verouderde gegevens, lees gegevens die niet meer in de moederdatabank zitten maar nog wel in de dochterbanken, worden op regelmatige basis verwijderd via een ander script in de dochterdatabanken) Per dochter worden een 18-tal tabellen geupdate. Indien ik de EDS variabel kan maken, los ik het in de RG van de moeder op met 18 TO's. Indien niet, moet ik het of manueel aanpassen na iedere run van het script, of moet ik 18x40 TO's maken ... En dat in een single-file solution met nu al meer dan 50 tabellen ... Nu doe ik dus nog veel manueel werk. Dat werkt wel, met dien verstande dat ik iedere keer na een serverscript-run, met een client de EDS in de moeder moet aanpassen en de server het script opnieuw laten runnen. Als je weet dat een update ongeveer 30 minuten duurt, kan je je wel voorstellen hoe lang het duurt vooralleer de laatste dochter geupdate is. Zeker als je weet dat de data minimaal één keer per maand geupdate dient te worden, dat ik 's nachts niet (meer) werk, er dat nog andere klanten zijn die geholpen willen worden. Hopelijk heb je nu een beter zicht op de probleemstelling ? PS: Als je nu eens kon importeren met een serverscript ... tja dan was het eenvoudig. Maar dat laat FM-server dus niet toe ! ("import records" is geen webcompatible-scriptstap )