(Automatisch) gegevens exporteren

[Stardust]

Wij maken gebruik van een bestand dat bestaat uit talrijke layouts (ca 200) en héél veel velden (ca 180). Dit bestand is met veel andere bestanden gerelationeerd (opzoeken postcodes bvb.).

 

Een gedeelte van deze gegevens dienen regelmatig aan collega's op de baan overgemaakt te worden, zij beschikken over een laptop maar niet over een internetverbinding.

 

Voor hen maakte ik een nieuw bestand met een voor hen geschikte (beperkte) layout en bestaande enkel uit de voor hen nuttige velden en relaties.

 

Deze nieuwe database zet ik met developer om naar een zelfstartende cd, zodat zij niet meer hoeven te doen dan de cd in de drive te steken en zo de gegevens kunnen raadplegen.

 

Het hoeft geen betoog dat deze procedure zeer arbeidsintensief is en ik ben dan ook reeds geruime tijd naarstig op zoek naar een eenvoudigere procedure. Echter tot op heden zonder resultaat, alo hetgeen wat ik dacht het ei van columbus te zijn, bleek achteraf helaas niet zo bruikbaar te zijn.

 

Ik vertrek van het idee dat het mogelijk moet zijn dat ik een soort van basisbestand maak met developer dat automatisch geupdated moet worden vanuit het moederbestand. Dit usr-bestand (inclusief de gerelateerde bestanden zoals bvb. de postcodes) moet dan d.m.v. scripting de volgende zaken kunnen doen:

 

1) Alle records verwijderen (geen probleem);

2) Alle bezette bestanden vanuit het moederbestand importeren:

a) Extern script in het moederbestand starten dat de gewenste

Find opdracht uitvoert (geen probleem);

b) Deze gevonden records vanuit het moederbestand (fp5)

exporteren naar het basisbestand (usr) (geen probleem);

c) Kopies opslaan naar de folder met het basisbestand (usr) als

usr-bestanden ter vervanging van de oude bestanden (dit is wel

een probleem, want dat schijnt niet te lukken Dze bestanden

zijn de nodige gerelateerde bestanden zoals bvb. de postcodes

maar ook nog verschillende andere bestanden waar ik helaas

niet veel meer kan over vertellen).

 

Ik vraag me dan ook af of dit mogelijk is of dat mijn systeem te complex is ? Wie kan er mij wat meer over vertellen want ik heb aan het zoeken geweest naar topics die ik kan gebruiken maar vind niet zo snel iets terug dat meer advies geeft omtrent mijn probleem.

 

Met vriendelijke zomergroet aan allen,

 

Danny[/url]

[Stardust]

Om het in feite beter uit te drukken ...

 

Ik heb een bestand(systeem) in developer waar ik de gegevens wil inbrengen van een fp5 bestandssysteem ...

 

 

is in feite wat ik wou zeggen hierboven

 

 

Alleen de gerelateerde bestanden geven problemen

 

Met dan aan allen,

 

Danny

[Rony Rabijns]

Danny,

Je hebt je uitgebreide basisbestanden (A) en je runtimebestanden (B). Ik zou vertrekken vanuit je runtimebestanden.

 

Verwijder alle records in je runtimebestanden (B)

Importeer de nodige records vanuit je basisbestanden (A)

Brandt de runtimebestanden (B) op CD.

 

PS : ik heb de indruk dat jij telkenmale een nieuwe runtime maakt ? Dat moet niet.

PS 2 : En USR bestanden kan je ook perfect openen met FM Pro. Het zal alleen niet standaard gaan via dubbelklik. Je moet je OS wel diets maken dat extensies USR geopend mogen worden door FM Pro ipv door de runtime applicatie.

[Stardust]

Dank je Rony,

 

Dat is inderdaad zo, je kan het usr bestand inderdaad gewoon met Filemaker openen. Ik heb het inderdaad gedaan zoals jij schreef.

 

Nu vraag ik me echter nog af of ik de bestanden die ik nodig heb voor de relatie niet gewoonweg kan copieren en hernoemen naar een usr-extensie, de layouts e.d. van de gerelateerde bestanden blijven toch ongewijzigd ? Of is de structuur van het usr-bestand zoveel verschillend van het fp5 formaat ?

 

Trouwens, het lukt me voorlopig nog niet om via een cmd bestand (batch) de benodigde bestanden te kopiëren, dit in een Windows XP Pro omgeving.

 

Ik vermoed dat dit te maken heeft met de naamgeving van de bestanden, deze volgen (helaas) niet de oude DOS standaard 8.3

 

Alvast bedankt voor je raad Rony !

 

Danny

[Rony Rabijns]

Nu vraag ik me echter nog af of ik de bestanden die ik nodig heb voor de relatie niet gewoonweg kan copieren en hernoemen naar een usr-extensie, de layouts e.d. van de gerelateerde bestanden blijven toch ongewijzigd ?

 

Ik ben niet helemaal mee denk ik.

Jij hebt toch een set met alle originele bestanden en een set met runtime-bestanden ? Ik neem aan dat toch enkel de data wijzigt en niet de structuur ? Maw de data moet toch maar van de originele bestanden naar de runtime-bestanden ? De runtimebestanden gebruik je dus telkens opnieuw ? Of zie ik het verkeerd ?

[Stardust]

Neen Rony,

 

Je ziet het niet verkeerd. Maar ik wil vanuit de set met de originele bestanden niet alles via een import/export opdracht naar de runtimebestanden overzetten. Dit gaat namelijk veel te langzaam, zeker wanneer je weet dat de bestanden nog in gebruik zijn door andere gebruikers. Er is maar één bestand waarvan de structuur wijzigt en dat is dus ook het enige van waaruit ik de gegevens van het originele moederbestand importeer.

 

Om tijd te winnen dacht ik, ik schrijf een batch bestandje (cmd) en laat al de andere originele bestanden (waar de structuur niet van wijzigt) gewoonweg kopiëren en wijzig de extensie naar usr. Dit alles in de hoop om het snel te laten verlopen. Of wil ik weer te veel

 

Nogmaals bedankt voor je aandacht Rony !

 

Danny

[RON7]

Misschien kan je de runtimes relateren aan het moederbestand,dan is er niets meer nodig.Na docken laptop kan men de data bewerken,eventueel nodige data aanvullen enz.(ongeveer zoals men een Pda dockt)

Maar zelfs enkel import/export zou vlug moeten gaan.Men moet immers enkel updates importeren ?

Ik begrijp wel niet waarom je structuur van 1 databank moet veranderen.

[Rony Rabijns]

Maar zelfs enkel import/export zou vlug moeten gaan.Men moet immers enkel updates importeren ?

 

Wellicht zijn er door de jaren heen veel berekeningsvelden ingeslopen gebaseerd op gerelateerde waardes ... (Eentje om dit probleem op te lossen, eentje om dat probleem op te lossen, enz ... ) En dat vertraagt inderdaad de import aanzienlijk.

 

Ik begrijp wel niet waarom je structuur van 1 databank moet veranderen.

Idem

[Stardust]

Ik begrijp wel niet waarom je structuur van 1 databank moet veranderen.

 

Ron7,

 

Daarvoor moet je m'n collega's kennen, vrees ik

Alleszins is het de bedoeling dat ze gewoon de cd krijgen, deze in hun laptop duwen en hoegenaamd niets kunnen wijzigen aan de gegevens en/of de structuur.

 

Ik vrees dat er inderdaad niets anders op zit dan alles via im-/export opdrachten te verwezenlijken maar gezien de omvang van de bestanden is dat vrij langdurig. Update v/d gegevens is inderdaad een optie maar ik moet dat nog eens goed uittesten. De gegegevens in het zogenaamde moederbestand zijn veel talrijker dan de gegevens die geëxporteerd dienen te worden naar het runtimebestand, daarom dat ik eerst altijd een zoekopdracht (gelukkig wel gescript en dus vrij vlug) dien uit te voeren.

 

 

Maar alle raad is natuurlijk welkom !

 

Thanks,

 

Danny

[RON7]

Dit kan je best allemaal scripten,je doet al een search in je moederbestand,leg deze vast per runtime.Vervolgens doe je een export met update;dus enkel wijzigingen worden aangepast en nieuwe data toegevoegd.Zal je al heel wat export tijd besparen.

[mikezwet]

Misschien begrijp ik het niet helemaal goed maar ik wil dit toch even toevoegen. Als je een runtim USR bestand wilt vervangen zit er altijd een Binding Key aan. (zie het menu van developer) Als deze binding key verschillend is met de rest van de runtime bestanden pakt de runtime de usr niet op. Maak je de binding key altijd hetzelfde kan je de usr bestanden gewoon uitwisselen en updaten.

 

Nogmaals, misschien niet van toepassing of je bent er al uit maar wie weet is dit een oplossing?

[Stardust]

Mike en eveneens alle anderen die mij goede raad gaven, wat dit project betreft, dit is even in de koeling geplaatst.

 

Met de raad van Rony en Ron kon ik al even verder en ik hoop binnen enige tijd het project vanaf scratch in elkaar te puzzelen. Andere werkzaamheden zijn echter dringender

 

Nu ben ik bezig met draken uit het verleden tot een lieftallig poesje samen te smelten, maar helaas is dit vrij arbeidsintensief

 

Vooral rekening houdend met het feit dat databestanden van meer dan 12 jaar geleden bvb. niet scrupuleus bijgehouden werden als heden ten dage (leve FM zou ik zo spontaan willen roepen)

 

Kortweg, ik beschik over een viertal databestanden, allemaal met gegevens van personen die een certificaat hebben gekregen. Deze certificaten moeten om de vijf jaar vervangen worden. In de eerste plaats moeten dus al de gegevens naar één bestand komen (of zou een relatie hier z'n nut kunnen hebben). Dit betekent dat de (gelijke) velden (voor zover die er al zijn) naar dezelfde naam moeten komen teneinde het importeren te vergemakkelijken. dan moet er een soort van trigger komen die meldt dat het certificaat dient vervangen te worden, hetzij 4 jaar en 10 maanden na de afgifte of na de voorgaande vervanging.

 

Dus nog veel werk dat ik hier tussen de soep en de patatjes moet zien klaar te spelen

 

Wie weet heb ik weer snel jullie raad nodig, die tussen ( jes ten zeerste gewaardeerd wordt !!!!

 

 

Greetz 2 All,

 

Danny