Ga naar inhoud

LcGrs

Leden
  • Items

    16
  • Registratiedatum

  • Laatst bezocht

  1. Ziet er mooi uit, maar wel behoorlijk ingewikkeld - of ligt het aan mij?
  2. Dit klopt, maar dan verlies je toch het voordeel (of is dat geen voordeel?) dat Filemaker zelf het beheer van gebruikersnamen doet.
  3. Hoi, Ik zoek me al een paar dagen kapot naar een antwoord op deze toch wel eenvoudige vraag: Hoe kan ik nagaan of een bepaald veld in een lay-out gewijzigd werd of niet. Bv. Ik wil kunnen nagaan of mijn gebruiker een veld geboortedatum (dob) gewijzigd heeft. Ondertussen heb ik gevonden dat met get(gewijzigde velden) een lijst kan verkregen worden van alle gewijzigde velden. Prachtig, maar ik weten of mijn veld dob daar tussen zit of niet. De oplossing zou moeten zijn: Filter (get(gewijzigdevelden);"dob")="dob" Dit blijkt niet te werken, want behalve "dob" komen er ook een hoop andere letters bij die ik niet nodig heb...
  4. Hoi, Ik heb een applicatie die wellicht als runtime gaat gebruikt worden. Er is voorzien dat er gebruikers aangemaakt worden (met gebruikersnaam en login). Als ik een nieuwe versie van die applicatie heb, kan ik de gegevens uit de oude database importeren naar de nieuwe database, maar wat met de gebruikers? Vermits FM17 alle info voer gebruikers (gebruikersnamen, logins en toegangsprofielen) afzonderlijk bewaard en je als gebruiker daar niet aankan, moeten alle gebruikers opnieuw aangemaakt worden telkens er een nieuwe versie (nieuwe versie van de applicatie, niet van FM dus) in gebruik genomen wordt?
  5. Hallo, Een vraagde betreffende de scriptactivering "bijvastleggenrecord". Ik had begrepen dat die uitgevoerd wordt voor dat de record vastgelegd wordt. De ideale plaats om te kijken of een clubnaam in mijn database reeds gebruikt werd (om dubbele namen op te vangen). Blijkt niet te werken. De wijzigingen in de record worden meteen vastgelegd en als ik in mijn script ga zoeken naar de recordnaam (in een afzonderlijke layout, gelinkt naar de tabel) dan vindt FM de benaming altijd. Ik kan dus mijn actie niet annuleren door het script te beëindigen met false zoals FM aangeeft? Wat is eigenlijk het nut van die scriptactivering "bijvastleggenrecord"? Of zie ik het allemaal verkeerd? bijvastleggenrecord.fmp12
  6. Nog wat lopen testen en dit blijkt het inderdaad te zijn. Een beperking: het gebruik van uitgebreide privilegesets lukt niet meer - maar da's niet zo erg: bij nader inzien lijkt het me geen sterk plan om eindgebruikers daarmee te laten spelen. Da's ook gelukt. Inderdaad vrij eenvoud te doen.
  7. Wat getest: Account gegevens in database bestand, geeft dat de database niet toegankelijk is zonder aanmelden met account en wachtwoord: perfect. Alleen kan het bestand met script geopend worden zonder inloggen en geeft deze toegang tot de gegevens in de database (zonder aanmelden met paswoord) - niet goed dus Blijkbaar moet de gegevens met accounts en privilegesets in het bestand met scripts, en een (1) wachtwoord op het bestand met de database zodat dit niet rechtstreeks kan geopend worden. Dit werkt wel, maar dan zit ik met een vraag: wat als je een nieuwe versie van het script installeert, wat dan? Je zou kunnen een script maken dat accounts uit de database laadt en nieuwe accounts aanmaakt met bijhorende scriptprivileges. Allemaal bruikbaar, maar wat met de instellingen van die privilegescripts? Moet de gebruiker die dan allemaal opnieuw instellen telkens er een nieuwe versie geïnstalleerd wordt? Da's onbegonnen werk... - Of niet?
  8. Hallo, Even een vraag (wellicht al voor wat gevorderden): Ik ben al een heel eind aan het experimenteren met Filemaker en... het loopt als een trein. Ontwikkelen gaat erg vlot en de samenwerking tussen FM Pro (server) en FM Go is geweldig. Ik heb hier een testversie van FM Server geïnstalleerd: ik heb nog nooit zo snel een server werkend gekregen (maar om eerlijk te zijn, ik heb ook nog nooit een server opgezet). 10' tijd en de zaak was draaiend. In loop hier ook wat te dromen over / experimenteren met wat in de toekomst een grotere toepassing zou kunnen worden (als het haalbaar is) en heb daarbij een vraag betreffende FM Server: Ik heb begrepen dat er via "Separate Data Format" een mogelijkheid is om de database en script in afzonderlijke bestanden te zetten, maar toch nog even deze vraag: wat dan met accounts en privilegesets? Moet dat in het bestand met scripts of in het bestand met de database? Het tweede lijkt me logischer, want als je het een nieuwe versie van het script installeert wil je niet dat de gebruiker alle accounts en privilegesets opnieuw moet installeren. Iemand tips? Bedankt!
  9. 't Is helemaal wat ik zocht... Alvast bedankt!
  10. Hoikes, Bijgevoegd een voorbeeldje van iets waar ik eigenlijk naar op zoek ben. Twee tabellen (hier clubs & spelers) met een formulier dat de clubgegevns vermeldt. Onderaan een aantal tabbladen, o.a. een lijst van de spelers, en dan had ik graag: [list=]Een portal met een lijst van de spelers (die heb ik) De gegevens van de geselecteerde speler in de velden rechts van de portal Dus, hoe kan ik het gedaan krijgen dat de gebruiker klikt op een van de spelers in de portal en dat het record van die speler weergegeven wordt in de velden rechts van de portal zodat aanpassingen kunnen gebeuren. Ik heb het zover gekregen dat een script reageert op aanklikken van een speler in de portal, maar dan zit ik verder vast... Enige tips? Bedankt voor de voorstellen. PS: ik heb niks voor of tegen KRC Genk, maar dat was de eerste ploeg die ik vast kregen, vermits die morgen blijkbaar een potje voetbal gaan plegen... clubs.zip
  11. Hallo, Ik ben al een tijdje op zoek naar een manier om via FM runtime een update van de database te kunnen doen. Zoals ik het begrepen heb kan dit best via een backup van de oude database en vervolgens importeren naar de nieuwe. Op welke manier kan ik aangeven dat die backup moet gebeuren naar een map 'backup' op het bureaublad (en vervolgens de import?) Ik heb al van alles geprobeerd maar geraak er niet uit. Ook de functie 'get(bureaubladpad) blijkt bruikbaar resultaat te geven. Of doe ik het helemaal verkeerd? Enige tips? Groeten, Luc
  12. Dat blijkt te werken... Ik had het helemaal anders gezocht... maar op deze manier werkt het perfect. Bedankt voor de tip, maar daarvoor zijn er mensen met ervaring waarschijnlijk...
  13. Ik heb een vraagje betreffende invoerlijsten (zie bijgevoegd voorbeeldje). Concreet werk ik op een reserveringssysteem voor overnachtingen voor medewerkers (en deelnemers) tijdens een meerdaags sportevenement. Ik wil hierbij graag een afzonderlijk scherm hebben voor aanvragen door medewerkers en aanvragen door deelnemers. In het bijgevoegde voorbeeldbestandje werkt de invoerlijst 'Alle medewerkers' niet. Kan iemand me zeggen wat er verkeerd gaat? Bedoeling is een venstermenu te maken waar alle medewerkers in voorkomen (en alle deelnemende clubs dus niet, dat zou op een ander scherm moeten komen). Bedankt voor de tips, want Ik zit een beetje vast! zandbak_14D05.fmp12
  14. Ik heb die quotes daar niet gezet. FM zet die quotes rond de zoekcriteria. In het scherm 'Zoekopdracht bewerken' staat als veld 'Sites slaapplaatsen::Verantwoordelijk' en als criteria '$zoek_contactpersoon', maar telkens zonder quotes. Daar ga ik later nog even naar kijken. Een probleem: het formulier dat open staat is het formulier voor de tabel 'Slaapplaatsen', terwijl mijn zoekopdracht bestemd is voor de tabel 'Sites'. In jouw voorbeeld moet ik eerst naar het formulier 'Sites' gaan - en dat is nu net niet de bedoeling.
  15. Ik ben beheerssysteem voor slaapplaatsen in elkaar aan het knutselen en zit momenteel toch een klein beetje vast. Even de situatie: Elke slaapplaats heeft een of meerdere sites (een-op-veel relatie tussen slaapplaatsen en sites) Elke slaapplaats heeft een aantal contactpersonen (een-op-veel relatie tussen slaapplaatsen en contactpersonen). Een contactpersoon kan verantwoordelijk zijn voor een site (een-op-een relatie tussen contactpersonen en sites) Het formulier Slaapplaatsen bevat een portal met gerelateerde contactpersonen. Naast elke contactpersoon heb ik een knopje "Wissen" geplaatst, dat knoptje start een script "Wis contactpersoon". In dat script wil ik eerst nagaan of een contactpersoon in de tabel sites vermeld staat als verantwoordelijk voor een site (in dat geval mag die contactpersoon niet gewist worden). En daar raakt FM helemaal de pedalen kwijt (gezien het prijskaartje dat aan FM hangt lijkt me dit vrij onwaarschijnlijk, wellicht ben ik het dus die de pedalen kwijt raakt? ) Wat is er mis met dit: #We gaan na of deze contactpersoon aangeven werd als verantwoordelijke voor een site slaapplaats Variabele instellen [ $zoek_contactpersoon; Waarde:Contactpersonen slaapplaatsen::ID ] Zoekopdracht uitvoeren [ Opgegeven zoekopdrachten: Records zoeken; Criteria: Sites slaapplaatsen::Verantwoordelijke: “$zoek_contactpersoon” ] [ Herstellen ] If [ Get(LaatsteFout) = 0 ] #Indien contactpersoon slaapplaats gevonden werd als verantwoordelijke voor een site mag deze contactpersoon niet gewist worden. De gebruiker krijgt een foutmelding en het script wordt gestopt. Zoekopdracht uitvoeren [ Opgegeven zoekopdrachten: Records zoeken; Criteria: Contactpersonen slaapplaatsen::ID: “$zoek_contactpersoon” ] [ Herstellen ] Alle records tonen Aangepast dialoogvenster tonen [ Titel: "Contactpersoon slaapplaats wissen"; Bericht: Contactpersonen slaapplaatsen::Volledige naam & " is verantwoordelijk voor site " & Sites slaapplaatsen::Benaming & " en kan dus niet gewist worden."; Standaardknop: “Annuleren”, Vastleggen: “Ja” ] Script afsluiten [ ] End If Het veld $zoek_contactpersoon bevat de ID van de contactpersoon en die komt voor in de tabel contactpersonen (ik heb net geklikt op een knop in de portal, naast de naam van de contactpersoon). Alles werkt tot aan de zoekopdracht. Daar levert FM mij een foutmelding 401??? Kan iemand me verder helpen? Bedankt!
×
×
  • Nieuwe aanmaken...