Werkwijze bij onderhoud van database met gebruikers

[Franks]

Hallo,

 

Ik wil onderhoud plegen aan een Filemaker database 6. Hierbij het gaat om veel aanpassingen die de nodige doorlooptijd vergen.

Maar ik kan natuurlijk niet de database een paar dagen uit de "lucht" halen om de aanpassingen te maken.

Bij het starten van de betreffende database worden ook nog twee andere gekoppelde Filemaker 6 database geopend die ook gehost staan op een server.

In de "hoofd" database zijn diverse aanpassingen noodzakelijk, denk aan:

- Velden toevoegen aan Database

- Auto-enter property uitzetten van een paar bestaande velden

- Veldnaam aanpassen

- Invoerschermlayouts wijzigen

- Printlayouts wijzigen

 

Heeft iemand een advies over welke werkwijze voor deze aanpassingen aan te raden is, waarbij de gebruikers zo min mogelijk hinder ondervinden?

In mijn documentatie stond helaas geen advies.

 

Alvast bedankt voor een reactie.

 

Groet, Frank

[hiker]

Ik heb gedurende twee jaar een dag per week bij een klant op lokatie gezeten om een databasesysteem te optimaliseren terwijl er 6 man mee werkten. Veel is te doen zonder dat de medewerkers het merken, veel is te doen tijdens koffie en lunchpauzes als het systeem wel even plat kan.

Als het systeem goed in elkaar zit kun je natuurlijk ook alles voorbereiden en de data ineens overzetten van oud naar nieuw systeem.

[tackenco]

Hoi,

 

Zo te lezen gaat het om drie tabellen? (meer mag ook hoor)

Als het ingrijpende dingen zijn waar je langer mee bezig bent en als het dingen zijn die mis kunnen gaan en dus eerst getest moeten worden. Als het daarnaast van belang is dat het bedrijfsproces niet stil komt te liggen, dan is het niet verstandig om te werken in de online database. Het risico is dan te groot dat er iets mis gaat en dat je backups terug moet gaan zetten waardoor alsnog al je werk verloren gaat e.d.

 

Ik zulke gevallen maak ik altijd een kopie. Ik doe alle aanpassingen en de hele test in die kopie (met de data die daar in staat). Daarna, als ik klaar ben en de opdrachtgever akkoord heeft gegeven maak ik de databases/tabellen leeg (ik gooi alle records weg of ik bewaar een kopie zonder records). Vervolgens kun je in een weekend of avond de import doen. Gebruik matching names als de veldnamen die er al in stonden niet gewijzigd zijn. Zorg ervoor dat eventuele automatische volgnummers bijgewerkt worden zodat je geen dubbele id's krijgt want dat geeft meestal ook problemen. De import is geen werkje wat je er even tussendoor doet, doe dat zorgvuldig en geconcentreerd!

 

Succes er mee

[Franks]

Hoi Hiker,

 

Bedankt voor jouw reactie.

Aangezien het hier redelijk wat wijzigingen betreft, lijkt het verstandig om eerst voor te bereiden en dan ineens de data over te zetten.

Voor andere wat kleinere wijzingen aan databases in het algemeen, ben ik wel nieuwsgierig welke soort aanpassingen je allemaal "online" kan doorvoeren terwijl gebruikers gewoon aan het werk zijn en toch geen last hebben van de werkzaamheden.

 

Ik heb begrepen dat Filemaker zelf het geschikte moment bepaald om gegevens op te slaan, in ieder geval bijvoorbeeld bij de invoer van gegevens via een invoerscherm. Ik kan me voorstellen dat als FileMaker op dezelfde manier handelt bij de layout van het invoerscherm, het kan gebeuren dat halverwege een aanpassing al bepaalde zaken zichtbaar worden voor de gebruikers.

Of worden de aanpassingen in een layout pas opgeslagen op het moment dat je van de Layout-mode weer naar de Browse-mode terug gaat?

 

Groet,

Frank

[Franks]

Hoi Tackenco,

 

Bedankt voor je reactie.

Het gaat inderdaad om redelijk veel aanpassingen die de nodige doorlooptijd vergen. Dus eerst op een backup testen lijkt raadzaam.

 

Ik heb nog wel een vraag over de opmerking: "Zorg ervoor dat eventuele automatische volgnummers bijgewerkt worden zodat je geen dubbele id's krijgt"

Bedoel je hiermee dat de optie "Perform auto-enter opties while importing" aan moet staan bij het importeren in de geprepareerde lege database?

 

Nu staat er onder andere een id-veld met de auto-enter property "Serial number" en een paar andere velden in de database die bijvoorbeeld automatisch met een initiele waarde "NO" worden gevuld en later worden gewijzigd naar "YES".

De waarde van het id-veld staat ook in de hulp-databases. Dit id-veld staat ook als RelationShip gedefineerd tussen de hoofd- en hulpdatabase.

Ik kan me voorstellen dat je een probleem krijgt als je data in de lege geprepareerde hoofddatabase gaat importeren en het id-veld door de optie "Perform auto-enter opties while importing", dus een hele andere (hogere) waarde zullen krijgen dan de bijbehorende records uit de hulpdatabase die verder niet aangepast worden.

 

Groet,

Frank

[tackenco]

Hoi Frank,

 

Ik bedoel dat terwijl je aan het programeren bent aan een een update wordt er gewoon doorgewerkt.

Er worden dus nieuwe records toegevoegd en de id's zullen dus oplopen.

In de applicatie waar je de update van maakt gebeurt dat niet.

 

Als je straks gaat importeren wil je natuurlijk dat alle oude id's mee geimporteerd worden want daar hangen tenslotte gerelateerde records mee aan elkaar.

Na de import moet je dan handmatig de waarde van de auto-enter aanpassen in het id veld.

Als je dat niet doet en er wordt een nieuw record aangemaakt krijgt die een id die al bestaat waardoor bestaande gerelateerde gegevens aan dat nieuwe record gekoppeld worden terwijl die daar niet bij horen.

 

Groet, Niels

[hiker]

Hallo Frank,

 

Je kunt redelijk veel wijzigen terwijl er gewerkt wordt in het systeem.

Ik heb velden aangemaakt, layouts aangemaakt en aangepast, scripts aangemaakt en aangepast, relaties gemaakt.

Er zijn een paar zaken waar je op moet letten bij het testen, en dat gaat voornamelijk over velden die automatisch ingevuld worden.

Als ik jouw rijtje aanpassingen lees, is er geen enkel probleem om dat in een werkend systeem aan te passen.

Velden aanmaken en wijzigen kan denk ik alleen in de koffiepauze, de rest kan altijd.

 

groet,

Hiker