Ga naar inhoud
  • 0

global veld op server aanpassen


pjotter

Vraag

Geplaatst:

De database op de server (met gewoon filemaker pro 7 draaiend) heeft 4 global fields en via een script dat gestart wordt via een client moeten deze worden aangepast. Dit laatste is echter niet het geval, na uitloggen en weer inloggen staan de global fields weer op hun oude waarde. Is het wel mogelijk om op deze manier global fields op een server aan te passen?

8 antwoorden op deze vraag

Aanbevolen berichten

  • 0
Geplaatst:
De database op de server (met gewoon filemaker pro 7 draaiend) heeft 4 global fields en via een script dat gestart wordt via een client moeten deze worden aangepast. Dit laatste is echter niet het geval, na uitloggen en weer inloggen staan de global fields weer op hun oude waarde. Is het wel mogelijk om op deze manier global fields op een server aan te passen?

Nee, dat kan niet. Maar waarom zou je? Stel de globale velden in, in het startup script en je hebt nog duidelijkheid in je scripts ook.

Als je het toch wilt wijzigen, moet je het bestand sluiten in FMS en openen met een gewone FM om daar de wijziging in te doen. Daarna weer openen in FMS.

 

René

  • 0
Geplaatst:

Dat is jammer, De 4 velden zijn namelijk de 4 soorten lidnummers die we hebben. <2000 gewoon lid, >1999 en kleiner dan 3000 partner, >2999 jeugd lid en >3999 begunstiger. Bij het aanmaken van een lid wordt het laatste lidnummer aangepast. Dus laatste nummer als lid was 1610 dan wordt er een nieuw lid aangemaakt met 1611 en wordt het global nummer aangepast van 1610 naar 1611. Dat werkt dus prima in de database op de lokale PC. Dan moet ik iets anders zoeken als oplossing hiervoor. :?

  • 0
Geplaatst:

Je maakt best een aparte tabel met die 4 velden in. De tabel heeft 1 record.

Telkens je een nieuw lid maakt, ga je via een script naar die tabel, je verhoogt het nummer, kopieert het (in een variabele), en komt er mee terug naar je vertrekpunt.

 

scriptmatig ongeveer zo (stel dat het een gewoon lid is dat lid wordt) :

 

new record

go to layout (instellingen) via een x-relatie

set field (gewoonlid) = gewoonlid + 1

set $variable = gewoonlid

go to layout (original)

set field (lidnummer) = $variable

  • 0
Geplaatst:
Dat is jammer, De 4 velden zijn namelijk de 4 soorten lidnummers die we hebben. <2000 gewoon lid, >1999 en kleiner dan 3000 partner, >2999 jeugd lid en >3999 begunstiger. Bij het aanmaken van een lid wordt het laatste lidnummer aangepast. Dus laatste nummer als lid was 1610 dan wordt er een nieuw lid aangemaakt met 1611 en wordt het global nummer aangepast van 1610 naar 1611. Dat werkt dus prima in de database op de lokale PC. Dan moet ik iets anders zoeken als oplossing hiervoor. :?

Daar zijn zo veel alternatieven voor. Plaatsen in gerelateerde velden is de snelste in gebruik maar het moeilijkst te maken om te voorkomen dat meerdere mensen tegelijk een nieuw nummer aanvragen. De makkelijkste maar traagste is met een interne relatie te bepalen wat het hoogst gebruikte nummer is. De allermakkelijkste is met een automatisch volgnummer maar ik krijg het idee dat dat niet helemaal bruikbaar is.

 

Overigens is het niet handig om een betekenis aan een lidnummer te geven. Een jeugdlid kan gewoon lid worden en krijgt dan een ander lidnummer!? Net als een barcode moet zo'n getal alleen maar een uniek, onveranderlijk getal zijn dat verwijst naar aanvullende gegevens in een database...

 

Groet en succes!

René

  • 0
Geplaatst:
Je maakt best een aparte tabel met die 4 velden in. De tabel heeft 1 record.

Hi, hi, gezien het tijdstip waren we gelijk met een antwoord bezig. :-)

 

Voor de eenvoud heb je fout-afvanging (multi-user friendly) even achterwege gelaten?

 

Groet,

René

  • 0
Geplaatst:
Voor de eenvoud heb je fout-afvanging (multi-user friendly) even achterwege gelaten?

 

Inderdaad. Het ging me even over het principe en het wel of niet gebruiken van globale velden. De addertjes zijn voor later. ;-)

  • 0
Geplaatst:

De opmerking over dat het niet handig is met de nummering is mij niet vreemd :D Zelf was ik er ook op tegen maar omdat men deze nummering al lang heeft (bijna 75 jaar) en omdat deze nummering ook al gehanteerd was in de vorige database (dbIII) en omdat deze nummering ook in de stauten staan wilde men dit toch handhaven. Ik moet ook zeggen dat ik nu ook om ben en ook regelmatig de voordelen er van zie. De oplossing van de extra tabel met de 4 velden daar was ik al mee bezig, ik had echter gehoopt dat het via de globals kon. Bedankt voor het meedenken ook via de email's

Doe mee aan dit gesprek

Je kunt dit nu plaatsen en later registreren. Indien je reeds een account hebt, log dan nu in om het bericht te plaatsen met je account.

Gast
Beantwoord deze vraag...

×   Geplakt als verrijkte tekst.   Plak in plaats daarvan als platte tekst

  Er zijn maximaal 75 emoji toegestaan.

×   Je link werd automatisch ingevoegd.   Tonen als normale link

×   Je vorige inhoud werd hersteld.   Leeg de tekstverwerker

×   Je kunt afbeeldingen niet direct plakken. Upload of voeg afbeeldingen vanaf een URL in

×
×
  • Nieuwe aanmaken...