upload records naar centrale db

[DBasine]

Ik heb een centrale db geshared door FM Server 5.5.

Er zijn gebruikers die, als ze buiten het bedrijfsnetwerk vertoeven, niet aan deze centrale db kunnen.

Daarom heb ik een lokale clone van de centrale db voorzien, een persoonlijk instrument voor elke gebruiker. Eens buiten de firma, openen ze deze clone en kunnen ze nieuwe records loggen. Komen ze weer op de firma, doen ze een UPLOAD van hun records naar de centrale db.

 

Mijn vraag:

hoe maak ik het veiligste UPLOAD-script?

Nu is het zo: men opent zijn lokale copie, en van daaruit kan men het UPLOAD-script uitvoeren. Deze is eigenlijk een external script van de centrale db die een import doet van de records van jouw locale copie. Maar het stomme is, hoewel men die locale copie heeft openstaan, men steeds moet verwijzen naar de fysische plaats van die lokale file (in de Import scriptstap). Heeft men dus per ongeluk meerdere lokale copies staan met dezelfde naam, zou hij een verkeerde kunnen nemen, wat zeer riskant is!!! Ik kan wel de Select File checkbox unchecked laten en de gebruiker zelf de file laten selecteren op zijn harddisk, maar dat is even gevaarlijk.

Als ik een export zou kunnen doen, die rechtstreeks wordt geïmporteerd in de centrale db, dat zou veiliger zijn. Maar dan moet ik nog steeds via een fysische file op de harddisk... terwijl ik gewoon wil zeggen: neem de records van huidig openstaande db. Voor de gebruiker komt dat heel verwarrend en ingewikkeld over.

[JeanWM]

In een ver verleden had ik een soortgelijk probleem met idem resultaten. Wat we ook probeerden, altijd was er wel iets (of iemand) dat de boel in het honderd deed draaien.

 

Uiteindelijk opteerde ik voor een methode waar de gebruiker het bestand parkeert op een vaste opgegeven plaats.

 

Als DB administrator deed ik een controle op het geheel, is het wel het juiste bestand, zijn de velden wel goed ingevuld etc.

En ik deed de upload naar het centrale bestand zelf.

Niks geen probleem meer, enkel wat meer werk.

In vergeliking met de hersteltijd voordien was dat te verwaarlozen.

 

Evenzo voor de download. We parkeerden een bestand op een vaste plaats en de externen konden het vandaar downloaden.

 

Het probleem van synchronisatie is een ander verhaal....

[Stardust]

Ik moet Jean bijtreden, na veel problemen met uploads heb ik uiteindelijk besloten slechts één verantwoordelijke al dit werk te laten doen. Nadat ik eerst getracht had alles te scripten zodat de gebruikers maar bij wijze van spreken op de (juiste) knop dienden te drukken, bleek alras dat er regelmatig van alles verkeerd liep. De nu gebruikte oplossing (ik doe het allemaal zelf) bleek uiteindelijk de beste te zijn.

 

Individuele gebruikers exporteren nu hun data naar een ander bestand en achteraf importeer ik alles in het master bestand, misschien omslachtig maar wel zo veilig.

[DBasine]

Jean en Stardust,

bedankt voor jullie snelle antwoord.

Maar Jean, wat was het probleem met download? Ik heb er geen problemen mee omdat de te importeren data uit een gesharede masterdb komen. Het is wel zo dat men daarna niet al te veel vrijheid meer heeft met het hernoemen, verwijderen of toevoegen van velden in de masterdb.

 

Wat ik ook nog kan doen, is de gebruikers hun data laten exporteren naar een hotfolder en van daaruit een watcher zetten (b.v. Visual Basic Script) die de records importeert in de masterdb?

Of de data mailen naar een toegewijd emailadres?

[JeanWM]

...wat was het probleem met download?

 

Dat lag eerder in de buurt van een toenmalige jeugdige onwetendheid.

 

De toepassing werd 'meegenomen' door externen.

Intussen waren wij vrolijk bezig met gevraagde aanpassingen en toevoegingen links en rechts, die allemaal prettig werkten, tot de externen hun (nieuwe) data terug gingen inladen.

 

Het opzetten van een soort agenda om te volgen wie, wat, wanneer 'meenam' en ook 'terugbracht', bracht daar al verbetering in.

 

Een kleine script die de synchronisatie deed, een lookup, import en synchro control, was voldoende.

 

Vandaar dat we een 'gekende mee te nemen versie' op een vaste plek plaatsten en de upload ook op een vast voorziene plaats, met een delete functie op de portable, om zeker te zijn dat altijd de juiste (laatste) versie werd meegenomen.

Daarna was het zaak om goed bij te houden welke versie 'nog onderweg was'.

 

Het moeilijkste was om de updating van data en de aanmaak van niuwe records te synchroniseren.

De laatst ingevoerde 'nieuwe' data is niet altijd de meest recente.....

Dat was een groot probleem naar de download toe....

 

We pasten de policy voor het 'meenemen' van data ook aan voor de portables. Zonder dieper in detail te gaan, de externen moesten o.a. de laptop inleveren en de HD werd vervangen (iedere externe had 2 HD's, niet iedere externe heeft dezelfde of alle software nodig voor zijn/haar job) door de IT afdeling.

Wij deden de down/up load zelf. Sindsdien bijna geen problemen meer, en nooit 'gevoeilige' informatie die ongeweten buiten de deur ging.

 

Voor zover ik weet is die policy nog altijd van toepassing.....