APUS is (net als de Systeembestanden) een 'raar' bestand. Dit, omdat in principe alle tabellen in Profit uniek zijn per Bestandenset (Testbestanden of Produktiebestanden), terwijl we van APUS (Gebruikers) maar één versie hebben, die zowel in de Testbestanden alsmede in de Produktiebestanden wordt gebruikt.
Bij een niet-ADS implementatie vinden we APUS.DBF alleen in de Testbestanden (FOXLOLOTF) en nooit in de Produktiebestanden.
Voor ADS geldt dat een tabel òf een Free Table is òf een Database Table (= een tabel die is opgenomen in een Data Dictionaty). Het is
niet mogelijk een tabel in de Test-DataDictionary én in de Produktie-DataDictionary op te nemen; de tabel weet van zichzelf dát ze al aan een Data Dictionary gekoppeld is, en kan maar bij één Data Dictionary horen.
Binnen ADS hebben we gesteld dat we twee Data Dictionary's hebben voor Profit, één voor de Testbestanden en één voor de Produktiebestanden. In theorie hadden we best één Data Dictionary (Profit) kunnen aanmaken, met daarin de tabellen van én Test én Produktie, maar, dit zou zo zijn nadelen hebben.
* Als we de Data Dictionary zouden willen backuppen, zouden we ook verplicht de Testbestanden moeten backuppen.
* Omdat het dezelfde Data Dictionary betreft, zouden we niet een kopie van de een naar de ander (of Backuppen in Produktie, om die backup vervolgens in Test te restoren) kunnen maken.
* De tabelnaam zou in de Data Dictionary uniek moeten worden gemaakt naar Test-/Produktie, en zou daarmee afwijken van de naam binnen Profit. We hebben immers ineens 2 Verkooporderbestanden, en die kunnen niet beide LOVO heten.
Hetzelfde probleem is ook aan de orde voor de SY database, daar is het net andersom, die hebben we alleen in FOXSYSYPF (de Produktiebestanden) en niet in de Testbestanden; de Testbestanden maken gebruik van dezelfde Systeembestanden als de Produktiebestanden.
Welke oplossingen zouden er zijn ?
a. Free tables Een oplossing zou zijn om alle SY bestanden en APUS te definiëren als zogenaamde Free Table. Een Free Table is een tabel die vrij op het netwerk mag staan. Klinkt leuk, maar de keerzidje is o.a. dat diverse beperkingen/rechten etc. niet ingesteld kunnen worden. Een Free Table mag ook geen ADT table zijn, en kan daarmee minder groot worden, en kan ook niet differentieel gebackupped worden. Je zou de tabel bijna net zo goed gewoon als VFP table verder kunnen laten gaan...
Deze optie valt al snel af.
b. Separate Data Dictionary voor SY en APUS Een tweede oplossing die ook leuker klinkt dan ze is, zou zijn dat we een tweede Data Dictionary aanmaken voor zaken die éénmalig binnen het pakket geregistreerd worden. We zouden een separate "Systeem" Data Dictionary kunnen maken die we vullen met de SY tabellen en met APUS. Vervolgens kunnen we vanuit zowel Test- als de Produktiebestanden connecten met deze Systeem Data Dictionary, en klaar...
Toch is dit om een aantal redenen verre van handig. Hoewel Profit technisch al in staat is om met meerdere Data Dictionary's tegelijk te connecten, mogen we problemen verwachten met het consistent houden van beide sets. Met 2 Data Dictionary's zullen er ook 2 Backupschripts moeten draaien, die van elkaar niet weten dat ze gedraaid hebben.
Ook geldt dat als we SQL Queries op de database willen loslaten, het niet handig uitpakt als we de tabellen over meerdere Data Dictionary's verdelen. Dit gaat dan al fout als we simpelweg de omschrijving van een User willen bepalen.
c. Tabellen toch dubbel opnemen Een andere oplossing zou zijn de tabellen alsnog gewoon dubbel op te nemen. Voor ADS geldt dan dat we én 2 Gebruikersbestanden hebben (1x in Test en 1x in Produktie) en dat ook de Systeembestanden én in Test én in Produktie aanwezig zullen zijn.
Hoewel dit de minst slechte oplossing is, en op zich niet al teveel kwaad kan (soms zelfs wenselijk is), impliceert dit dat "Gebruikers" en "Systeembestanden" nu uniek zijn naar de aktieve bestandenset. Ach, v.w.b. de Logistieke- en Financiële bestanden is dat ook zo. Is dat nou erg ?
Ja en Nee. De een zal het een voordeel vinden, de ander een nadeel.
Ooit hebben wij ervoor gekozen om maar één versie van deze tabellen te hanteren. Dit, omdat het niet handig is dat als we een nieuwe Gebruiker opnemen, we dit 2x moeten doen (1x voor Test, en 1x voor Produktie). Met dat de Gebruikerstabel gelijk is voor Test en Produktie, zijn we er ook meteen van gegarandeerd dat de toegevoegde Gebruiker in zowel de Testbestanden als de Produktiebestanden dezelfde Userid heeft.
Gelukkig is dit geen onoverkomelijk probleem; zovaak voegen we geen Gebruikers toe. Voordeel zou zelfs kunnen zijn dat we nu een Gebruiker écht alleen maar voor de Testbestanden kunnen definiëren en wiens Identifikatie helemaal niet bekend is in de Produktiebestanden (laat staan dat de Testgebruiker ooit kan omschakelen naar Produktie).
Advies is overigens wel om bij het aanmaken van een nieuwe Gebruiker, diens Userid direkt in de Produktiebestanden én in de Testbestanden aan te maken. Een Gebruiker die in Produktie werk, wil nl. kunnen omschakelen naar de Testbestanden, en een Gebruiker die in Test gedefiniëerd is, zal op enig moment naar Produktie kunnen willen, en dan is het niet handig als zijn Userid daar door een andere persoon al gebruikt wordt. Opletten dus bij het inrichten hiervan.
Een groot voordeel van een separate Gebruikerstabel voor Test- en Produktie (danwel Systeembestanden voor Test- en Produktie) is dat we de Testbestanden separaat van de Produktiebestanden kunnen upgraden of reorganiseren, zonder dat de Gebruikers in de andere bestandenset eruit hoeven. Zo geldt dat bij aanwezigheid van de module
Profit-Base-Test de Testbestanden ook van aparte Testprogrammatuur wordt voorzien, en we dan in Test een Upgrade kunnen uitvoeren terwijl de gebruikers in de Produktiebestanden kunnen doorwerken.
De gebruikerstabel bevatte echter ook een parameter waarin werd bijgehouden met welke Bestandenset (Produktie- of Testbestanden) de Gebruiker als laatste gewerkt had. Deze informatie werd gebruikt om de Gebruiker, bij opnieuw inloggen, automatisch weer terecht te laten komen in de laatst gebruikte bestandenset.
Als een Gebruiker omschakelde naar de Testbestanden, zijn-/haar sessie beëindigde, en later Profit weer opnieuw opstartte, dan kwam hij/zij weer opnieuw terug in de Testbestanden.
Deze setting is v.w.b. ADS uit de APUS tabel geëlimineerd. De setting wordt nu bewaard in een separate Free ADS Table (geen onderdeel van een Data Dictionary, en kan daardoor gedeeld worden door Test- en Produktie).
| Funktie | Omschrijving | Dtm.Vl.Wyz | Dtm.L.Wyz |
| APUSTV | Toevoegen Gebruiker-gegevens | 26-09-2014 | 24-11-2014 |
| APUSVW | Verwijderen Gebruiker-gegevens | 25-11-2014 | 25-11-2014 |
| LOINU | Intoetsen User-id | 30-09-2014 | 25-11-2014 |
| LOINUSLS | Omschrijving (nog) niet bekend | - - | 25-11-2014 |
| LOINUUBB | Omschrijving (nog) niet bekend | 30-09-2014 | 25-11-2014 |
| SYBHBAKO | Omschrijving (nog) niet bekend | 20-11-2014 | 21-11-2014 |
| SYKO | Omschakelen Bestanden | 16-10-2014 | 24-11-2014 |
| SYKOINU | Omschrijving (nog) niet bekend | 11-11-2005 | 24-11-2014 |
| SYSS | Omschrijving (nog) niet bekend | 21-11-2014 | 25-11-2014 |
