database upgraden

[tomstoek]

IK bouw databases voor "klanten" en programmeer eigenlijk alles lokaal bij de klant (of via VPN).

 

Nou zou ik graag bij mij de database aan willen passen en dan een soort upgrade uit willen voeren.

 

Als je de developers instructies leest dan kan dat alleen door:

Thuis de database aanpassen

bij de klant de data te importeren uit de oude database in de nieuwe database.

 

1) Is er niet een oplossing om de tabellen waar de lay-outs en de rest van de db-gegevens in staan te exporteren en bij de klant in te lezen (importeren)?

 

2) Als ik de gewone data moet importeren is er dan een manier om een complete database te importeren en niet per tabel?

 

Wie kan mij op weg helpen

[Felix]

.

4 oktober 2015 aangepast door Gast

[hans erik]

1) Is er niet een oplossing om de tabellen waar de lay-outs en de rest van de db-gegevens in staan te exporteren en bij de klant in te lezen (importeren)?

 

2) Als ik de gewone data moet importeren is er dan een manier om een complete database te importeren en niet per tabel?

 

Ik zou zoals Felix aangeeft 'gewoon' de data en interface over twee FMP bestanden verdelen. Je hebt dan één FMP bestand met alle tabellen met gegevens. Die hoef je sporadisch te wijzigen, alleen als er een velddefinitie aangepast moet worden. Het andere bestand bevat de layouts, scripts, keuzelijsten, kortom alles wat je regelmatig op verzoek van de klant moet aanpassen.

 

Je kunt gemakkelijk een nieuwe versie van je interface bestand installeren zonder ook maar één record te moeten importeren. Je kunt zelfs meerdere versies van je interface bestand naast elkaar gebruiken, die van dezelfde data gebruik maken.

 

Alleen,... om een bestaande toepassing om te zetten naar een gescheiden model vergt wel enige voorbereiding.

 

Het werkt ongeveer zo, in drie stappen:

 

1. voorbereiding

- maak een duplicaat van je database, noem het origineel bijv. xxx_data en het duplicaat xxx_user.

- maak in xxx_user een link naar xxx_data, niet andersom, het is éénrichtingsverkeer. Doe dit met behulp van Manage>External Datasources in xxx_user (waarbij je xxx_data als external datasource aangeeft).

 

2. En dan in xxx_user:

- open Define Database en verander ALLE Table Occurrences (TOC's) door ze een voor een te dubbelklikken en dan de brontabel te 'verleggen' van de 'interne' (xxx_user) naar de 'externe' datasource (xxx_data). Je zult waarschijnlijk een hoop TOC's hebben, dus om goed in de peiling te houden welke je al gehad hebt, geef je ze eerst allemaal een groen kleurtje en na 'ompluggen' een paars kleurtje. Dit is een vervelend klusje, want je moet de naam van elke TOC herstellen zodra je de sourcetabel hebt veranderd. Geestdodend seriewerk.

 

MAAR: als het goed is moet elke layout in xxx_user na omzetting precies dezelfde data laten zien als voor de omzetting!

 

- als je helemaal klaar bent, kun je in principe alle tabellen in xxx_user weggooien!

Je hebt voor login etc. misschien wel een paar hulptabelletjes nodig in xxx_user, hangt ook van je interface af.

 

3. En daarna in xxx_data:

Hier kun je alle TOC's die je niet nodig heb, verwijderen. Evenals alle scripts en layouts.

Maar let op: als een TOC/relatie nodig is voor de datadefinitie (in een formule, een lookup oid) dan moet je hem niet weggooien natuurlijk, want dan verstoor je de werking van je database.

 

Dit is vooral een heel secuur klusje, dat gemakkelijker is naarmate je je database beter hebt gedocumenteerd. Draai bijv. een DDR uit.

 

Wat je overhoudt is

- een xxx_user met alle layout en scripts en alle TOC's met relaties

- een xxx_data met alle tabellen, een paar noodzakelijke scripts en layouts en alle relaties die voor de velddefinities noodzakelijk zijn.

 

De security regel je natuurlijk in xxx_data.

 

Er zijn nog wel wat zaken die ik hier niet genoemd heb, maar in grote lijnen is dit het.

 

Hans Erik

[burggraaf]

Allemaal waar alleen... Als je de applicatie aanpast/verbetert zul je veelal ook extra velden in je datatabel(len) willen hebben. Dat vergt dan ook een update van je 'data'-bestand...

[hans erik]

Dat klopt, maar meestal blijven de wijzigingen in de datafile beperkt tot een paar velden erbij. Mijn strategie is dan:

 

- als het om 1 of 2 velden gaat, repliceer ik die wijzigingen meteen in mijn eigen kopie (wel in de juiste volgorde, want die bepaalt meestal welke velden in formules en scripts worden gebruikt, niet de naam van een veld).

- moet er een een hele tabel bijkomen, dan breng ik de wijzigingen aan bij de klant (via remote login) en haal dan de backup over zodat mijn eigen versie weer in de pas loopt.

 

Zaken waar je rekening mee moet houden zijn vooral externe koppelingen (met ODBC bronnen), Remote Container opslag en functies waarin een naam van een veld wordt berekend, zoals ExecuteSQL.

 

Om een idee te geven: bij een redelijk grote klant heb ik het databestand nog NOOIT meer hoeven importeren, sinds ik de data ooit van FileMaker 6 omgezet heb naar FileMaker 10 (nu: FileMaker Server Advanced 12). Het interface bestand is al talloze malen vervangen door een nieuwe versie, en vorig jaar uitgebreid met een tweede interface speciaal voor IWP.

[Timke]

Ik splits mijn database ook telkens op in een user en data file..

 

Als je van die database nu een runtime-solution maakt, kan je dan nog steeds gewoon het user-gedeelte over de vorige versie heen zetten zodat gewoon nog steeds dezelfde data-file gebruikt wordt?

 

En wat wanneer je een runtime-solution maakt voor Mac en eentje voor Windows (want die moet je voor elk platform specifiek maken dacht ik)?

Kan je dan ook nog steeds gewoon de data overnemen van de ene runntime-solution(windows) naar de andere (Mac)?

[hans erik]

Ik heb eerlijk gezegd met de FMP11 en 12 runtime niet zo'n ervaring. Ik denk dat je de userfile als primary file moet koppelen aan de Runtime, maar of je die dan gewoon kunt vervangen door een nieuwe versie (mer dezelfde bind-key),...

 

Ik ga het eens proberen.

 

HE

[Felix]

.