Ga naar inhoud
  • 0

Separate data format op server: wat met accounts?


LcGrs

Vraag

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!

Link naar reactie

Aanbevolen berichten

  • 0

We kunnen heel lang en erg vaak over al deze methodes discusseren.

 

Feit is dat de huidige stand van Filemaker dit allemaal wel zo ongeveer mogelijk maakt, met hier en daar een nadeeltje.

De angst is dat we niet weten wanneer en hoe Filemaker oude gedachtes gaat loslaten.

Zolang ze alles blijven ondersteunen is er weinig aan de hand.

 

Omwille van onvoorziene omstandigheden zoals het onderwerp in dit topic, hou ik het zelf ook liefst zo simpel mogelijk.

Dus geen data - ontwerp scheiding.

Je ziet het hier gebeuren. Een nieuwe functie zoals Server sided scripting is blijkbaar onvoldoende getest op deze scheiding.

 

Dan blijft over om het Filemaker zelf te melden, zodra je fouten ziet ontstaan.

Link naar reactie
  • 0

Onze favoriete werkwijze

- 1 bestand met alles erin. (ancher en buoy methode, eventueel bij een zeer grote hoeveelheid in 1 tabel deze splitsen.)

 

Houd je dan binnen je relatiediagram aparte TO groepen met alleen TO's voor de datadefinitie aan? Met andere woorden: hoe voorkom je dat je in een heel groot en complex schema de verkeerde context pakt als je een berekend veld of een lookup toevoegt?

 

Ik heb wel altijd een 'hoekje' in mijn schema met daarin een 'referentie-TO' voor elke tabel, die ik nooit een andere naam geef ofzo. Alle ExecuteSQL maken gebruik van deze TO-namen, zodat ik me nooit hoef te bekommeren om naamgeving (SQL is ook nog eens hoofdlettergevoelig, dus het luistert allemaal heel nauw en ik heb niet zo'n trek in allerlei extra berekeningen die de SQL onleesbaar maken). Maar een veldnaam veranderen is iets wat ik niet zomaar doe dus.

Link naar reactie
  • 0
Houd je dan binnen je relatiediagram aparte TO groepen met alleen TO's voor de datadefinitie aan? Met andere woorden: hoe voorkom je dat je in een heel groot en complex schema de verkeerde context pakt als je een berekend veld of een lookup toevoegt?

 

Nee gewoon in het ancher buoy model rood voor delete en groen voor aanmaken etc...

We ervaren geen probleem met onze software oplossing (azorsoftware.nl) in 1 file die de volgende modules bevat. (bedrijven,relaties,facturen,inkoopfacturen,urenregistratie,todo's,planning,kosten,documenten,agenda,offertes, management, meertalig en multicurrency. 115 tabellen).

Het is voor ons een genot om 1 file te hebben. Denk aan updates, demos, customfuncties, variable, rechten backups etc. Filemanagement is gewoon een stuk makkelijker.

 

Ik heb wel altijd een 'hoekje' in mijn schema met daarin een 'referentie-TO' voor elke tabel, die ik nooit een andere naam geef ofzo. Alle ExecuteSQL maken gebruik van deze TO-namen, zodat ik me nooit hoef te bekommeren om naamgeving (SQL is ook nog eens hoofdlettergevoelig, dus het luistert allemaal heel nauw en ik heb niet zo'n trek in allerlei extra berekeningen die de SQL onleesbaar maken). Maar een veldnaam veranderen is iets wat ik niet zomaar doe dus.

 

Wij werken het liefst zo min mogelijk met ExecuteSQL en als we het gebruiken dan vaak op de manier zodat je nog de veldnaam kan wijzigen. Denk ook aan het probleem dat je met baseelements niet meer kunt checken of iets unreferenced is. Denk aan het probleem dat ExecuteSQL een andere engine is die de resultaten in een ander formaat teruggeeft etc...

 

Nou ja om het verhaal maar af te sluiten denk dat je niet kan zeggen welk model beter is. Er zijn argumenten voor alle 2 de kanten te bedenken. En een specifieke situatie kan ook bepalen welk model beter past. Ik denk dat het ook verschilt of je met meerdere mensen aan 1 oplossing werkt of alleen. Dus met andere worden tal van redenen om voor iets te kiezen.

Link naar reactie
  • 0
Nou ja om het verhaal maar af te sluiten denk dat je niet kan zeggen welk model beter is. Er zijn argumenten voor alle 2 de kanten te bedenken. En een specifieke situatie kan ook bepalen welk model beter past. Ik denk dat het ook verschilt of je met meerdere mensen aan 1 oplossing werkt of alleen. Dus met andere worden tal van redenen om voor iets te kiezen.
En zo is het maar net, wat voor mij perfect werkt hoeft voor een ander helemaal niet de juiste weg te zijn.
Link naar reactie
  • 0

Inderdaad, zoveel zinnen...Neemt niet weg dat de mogelijkheden om met meerdere mensen aan één oplossing te werken niet geweldig zijn.

 

Zoals WJ aangeeft, werken zij met meerdere personen tegelijk aan Azor,en dan houdt één bestand het wel iets overzichtelijker. Wat telt is dat FileMaker maar heel beperkte mogelijkheden heeft om scripts en layouts uit te wisselen zonder fatsoenlijke controle over wat er gebeurt.

 

ID's van velden, scripts en layouts displayen in FMPA zou al enorm helpen, beter is het nog als je die ID's ook zou kunnen wijzigen, om een foute mapping te kunnen corrigeren. Moet je natuurlijk heel voorzichtig mee zijn, maar ik denk dat FileMaker deze zaken toch al ergens in een soort catalog bijhoudt. Per slot van rekening kunnen bepaalde SQL plugins wel degelijk velden dynamisch aanmaken!

Deze toegang zou ook de meerwaarde van FileMaker Pro Advanced aanzienlijk vergroten. En dan ook gelijk een goed importmodule voor tabeldefinities en layouts.

 

NB je zou ook allerlei trucs kunnen toepassen zoals het toevoegen van het veld ID aan de naam (oei!) of in het commentaarveld, maar het blijven 'oplossingen' voor problemen die FileMaker allang had moeten aanpakken.

Ik hoop echt dat FileMaker 14 dit soort zaken gaat adresseren.

HE

Link naar reactie
  • 0

Mjah...

 

Ik hoop van niet.

 

De reden is dat ik ook met MS-Access heb mogen werken.

Daar kan je van alles aanpassen, zodat je vooral nergens toe gedwongen wordt.

Heerlijk, vrijheid! Ik als Individu wil mij vooral niet de wet laten opleggen door iemand anders. Geweldig!

 

Binnen de kortste keren ben je het overzicht kwijt, is het instabiel, kost het veel tijd om het te doorgronden.

Gelukkig heb je met MS-Access volledig recht op de door jezelf veroorzaakte problemen.

 

Juist doordat Filemaker zo haar beperkingen kent, wordt je gedwongen in het keurslijf van Filemaker te lopen.

Filemaker is daarom wat het is. Een verrekte simpel te onderhouden tool, zonder af te kunnen dwalen in technische vrijheden.

 

Ik leg daarmee wel een flink stuk vertrouwen in de handen van Filemaker.

En ik heb dat ook. De afgelopen 20 jaar hebben ze mij nog nooit in de steek gelaten.

Link naar reactie
  • 0

Tja volgens mij hadden we deze discussie niet gehad als FileMaker gewoon een goede versie en update management tool had. Andere omgevingen hebben bijvoorbeeld github.

Dit hebben we echt nodig als je het mij vraagt. Tot die tijd is het behelpen. Of vaak data updates of vaak interface files verwisselen beide niet heel erg prettig.

 

We ontwikkelen niet tegelijk in 1 bestand(meestal moet ik zeggen.) Wat we doen is de aanpassingen in een aparte versie maken vervolgens ter controle aanbieden aan een andere ontwikkelaar na goed keuring code overzetten in 'echte versie'

 

Groet,

 

WJ

Link naar reactie
  • 0

Gelukkig heb je met MS-Access volledig recht op de door jezelf veroorzaakte problemen.

Dat ben ik wel met je eens, ik heb zelf ook jaren met Access gewerkt, waarbij ik me angstvallig beperkt heb tot de query- en analyse functies. Dus geen geklieder met scripting en Visual Basic, en ook geen forms. Alleen SQL eigenlijk.

 

Access is voortgekomen uit FoxBASE (de database Engine), voorzien van een soort excel-achtig interface bouwsel. Word je niet vrolijk van.

 

FileMaker is door de jaren heen veel professioneler geworden en dat is alleen maar goed, maar het schept verwachtingen. Ik vind de manier waarop scripts, layouts, velden en tabllen met ID's in elkaar grijpen prachtig: ik kan in een interface file alle 180 Table Occurrences volgens een nieuw naamschema hernoemen zonder me één seconde zorgen te maken dat een script of layout het niet meer doet (nou ja, bijna).

 

Dat wil ik graag zo houden, maar ik zou ook graag de mogelijkheid willen hebben om 'onder de kap' te kijken als er wel iets is wat problemen geeft.

Bijvoorbeeld als je een tabel, layout of script van het ene bestand naar het andere kopieert, of bij importeren van bestanden.

 

HE

Link naar reactie

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...