Database stabiliteit

  • Ron Kroese
  • Auteur

Re: Database stabiliteit

23 jun 2014 12:12
#1077
Het verbaasd me wat men allemaal aanneemt mbt mijn database probleem. Ik zal er het maar op houden dat mijn Nederlands niet zo goed is als ik dacht, om in mijn eigen taal (Engels) verder te gaan vind ik een beetje flauw, dus ik laat het er maar bij.

Achter af was het omzetten van "zeer groot voorgeslacht1.6" naar "extremely large ancestry-1.61" makkelijker dan ik dacht. Toen ik probeerde mijn oplossing te plaatsen bij sjablonen bleek die vraag al gesloten te zijn. Wel zag ik dat er vergelijkbare oplossing geopperd waren.

In ieder geval voor diegene die geïnteresseerd zijn:

:. RK 1.61 20-06-2014 Added English Libraries
:.
Sjabloon 'Extremely Large Ancestry' Version _Versie
COMMENTAAR
_METAINFO
_METAPATH("c:\aldfaer\zgvrgeslcht\", "g", "c") :.
:. Maak de initiele sets en vul een voorgeslacht
:. =============================================
:.
_METAPRIVATE( "filter" ) :. Schakel filter in, indien gewenst door de gebruiker
_METAEND
_USES( AncestorsHook ) :. Overrule standaard functies
_USES( EnglishBasis ) :. English subroutines
_USES( Basis ) :. Basis routines gedeelt met nageslacht en persoonskaart
_USES( EnglishDateFormat ) :. English Date formating
_USES( DutchDateFormat ) :. Datum formattering

Ik krijg twee fout melding in zowel de originele Nederlandse versie als mijn Engelse.
1) Absoluut pad in _METAPATH, overweeg hier relatief tov output map,op regel 49 van large ancestry.asj
2) Parameter C bij _METAPATH wordt niet meer ondersteund,op regel 49 van large ancestry.asj

Verder werkt het naar behoren.

Mijn dank aan diegene constructief mee gedacht hebben.
Onderwerp is gesloten.
Lees meer

Re: Database stabiliteit

23 jun 2014 12:42
#1079
Ron,
it never crossed my mind that you were busy changing a template, unkown to me.
It contains is a very old coding and as far as the error message is concerned you should use the simple code _METAPATH([:_FILEPATH:]) For reasons of security a template should always use its own output path as specified in the Aldfaer settings for files.
Onderwerp is gesloten.
  • Ron Kroese
  • Auteur

Re: Database stabiliteit

24 jun 2014 13:44
#1092
Hans,

Thanks for the info however mij first quick attempt to modify the program as you suggested failed and the application hung.
I'll look into it when I get a bit of time, in the meantime I'll live with the twee warnings.

Where can I find the "Aldfaer settings for files", this will save a lot of time browsing though various programms. Also, is there a "Reference Guide" for the subroutines and functions

Ruud,
You win, even if I count my 4 years process engineering with PLCs, analog- and digital mini- computers and 6 pensioned years of playing with PC's (linux), I only come to 51. :-))
Een ding kan je zeker van zijn is dat ik nooit... nooit iets test met een "live database".

Ron
Onderwerp is gesloten.
Lees meer

Re: Database stabiliteit

24 jun 2014 17:08 - 24 jun 2014 17:11
#1093
Ron,
I'd rather talk about changing a template as opposed to changing a program. One cannot change the Aldfaer program (executable), therefore, there are no subroutines etc to be changed. The only item for users is to make use of templates, allowing to access the database by means of a template parsor.

I have pointed you to the setting of files, which can be altered thr "Extra -> Instellingen -> Rapporten -> Bestanden" I have a feeling that under the capture "Rapportuitvoer" you have a non-existent path or no path at all. That might be the reason that the tag _FILEPATH gives an error.

In future please state that you are changing a template rather then making remarks like 'loosing parts of the database', which as explained is just not possible. Rightfully everybody jumps on you. In a template however it is possible that a part of the database is omitted when a wrong coding (tag) is used.

Further, I do not know if you have installed the so-called "Bonusrapporten" plug-in or the list of all available 'official' plug-ins. In that list there is even a plug-in which applies an English menu for Aldfaer. The 'Help" remains in Dutch. The list contains also another link to install a "Handleiding sjablonen", thus a perfect research for you in case you want to devellop or change templates.

The list I'm referring to is called "Alle invoegtoepassingen B_team" . On the old Aldfaer website under the capture 'Downloads' you may read how to install the 'Invoegtoepassingen" (plug-ins)

By the way, the name is Han
Laatst bewerkt 24 jun 2014 17:11 door Han Kortekaas.
Onderwerp is gesloten.
  • Ron Kroese
  • Auteur

Re: Database stabiliteit

25 jun 2014 14:34
#1096
Han,

Sorry about the naam. I have a terrible memory for names and like most e-mailers I don't allows check the spelling as I should.

Even in volgorde van boven:
1)Ik heb nooit de hoofd executable willen veranderen en naar mij weten heb ik dat nooit beweerd. Ik begrip dat Windows terminologie anders is dan IBM mainframes dus ik zal proberen me waar mogelijk aan te passen. Al zal ik blijven denken in mainframe terminologie.

2)De setting dat jij noemt staat op default, dwz. "C:\Users\ron\AppData\Local\Temp\", tot nu toe heb ik geen reden gehad om dit te wijzigen. Ik zal heb even aanpassen naar "D:\family\Aldaer\reports\ en testen op een kopie database.

3)Ik begrijp dat "loosing parts of the database" behoort onmogelijk te zijn, maar zelfs mijn Nederlands is niet zo slecht dat ik niet kan zeggen wat ik bedoel. Als ik (bijvoorbeeld) op een dag ruim 1000 personen in mijn database heb en een paar dagen later maar 800 dan ben ik ze toch echt kwijt. Als ik dan een "personenlijst" maak en zie dat alle personen wiens achternaam begint met een A en/of een B dan kan ik (denkt ik) ze als "lost", "verloren" en/of "verdwenen" beschouwen. Ik heb de database daarna ook nog eens bekeken met een hex-editor en kon alles behalve de vermiste data vinden. Alles netjes in blokken (of in mainframe termen) in tabellen, de personen in alfabetische volgorde voor op.

Omdat ik met kleinere rapporten geen probleem had gevonden, had ik ook geen bijzondere maatregelen genomen om eea extra te beveiligen, behalve de 20 beveiligingsbestanden die automatisch gemaakt worden bij afsluiten van de executable. Omdat ik (zeker toen) zo druk was met het vullen en verzamelen van data en materiaal (aktes en fotos) dat ik wel 3 @ 4 keer per dag aan- en uit-logde, dus de 20 backups waren er zo door heen voor dat ik het vermis in de gaten kreeg. Het enige waar ik, opdat moment, mee bezig was, was het samenstellen van rapporten met de beschikbare "sjablonen", functies of subroutines (hoe je ze ook wil noemen).

Om eea te herstellen heb ik kleine/ander Aldfaer databases gecreëerd van heel oude gedcom bestand gemaakt in PAF en Gramps, na het verwijderen van overtollig materiaal, het resultaat exporteren en importeren in mijn centrale database.
Uiteraard kan je niet alles verwijderen want dan verlies je huwelijks data, MAAR... dit creëert dubbele personen, vandaar mijn opmerking mbt het gemis van een goede merge programma/functie/subroutine/sjabloon.(Wat ever.)

Ik zal de opmerking "Rightfully everybody jumps on you." en "kleuren buiten de lijntje" maar beschouwen als een misverstand in vertaling.
By the way: het roepen van "DAT KAN NIET" veranderd de feiten niet en is ook niet "helpful".
Hoe dan ook, ik zal moeten wennen aan jullie gebruik van het woord "tag" wat letterlijk "lable" of etiket betekent vooral als je parameter bedoeld.

4)Ik heb zowel de Bonus als Engelserapporten4103 add-ons van jullie site gedownload en geïnstalleerd via de voorgeschreven methode dwz Help/Versiebeheer invoegtoepassingen. "Alle Invoegtoepassingen B_team" het ik nog niet geïnstalleerd omdat er tot nu toe geen reden voor was, maar ik bekijk het tezamen met punt 2)

Als laatste opmerking is er "Trace" die aan kan zetten, huidige log zegt niet veel.

Om dit soort verwarringen te voorkomen misschien zou het handig zijn om een sjabloon te maken voor problemen waar alle data die jullie nodig hebben in staat. bv. apparatuur, hulp programma's, bestandslocaties enz.

Groetjes

Ron
Onderwerp is gesloten.
Lees meer

Re: Database stabiliteit

25 jun 2014 16:02
#1097
Ron,

in alle jaren dat Aldfaer nu draait heb ik van niemand ooit gehoord dat er delen van de database zomaar weg zijn en geloof me dat er zeer veel gebruikers zijn.
Ik kan me dus alleen maar voorstellen dat in het afsluiten van de database (1) een storing is opgetreden of (2) je bent simpelweg vergeten de vraag van Aldfaer bij het afsluiten ("wijzigingen opslaan") positief te beantwoorden.

Het Aldfaer *.aldf bestand wordt bij opening gesplitst in een verborgen map in ca 44 bestandjes *.alf waar de mutaties in worden bijgehouden. Bij het afsluiten worden deze *.alf bestandjes weer samengevoegd to *.aldf. Als door een onvolledige afsluiting (stroomstoring, abrupt beëindigen van de executable, automatische back-up die bestandjes vasthoudt, idem synchronisatie) het samenvoegproces onderbroken wordt dan is het maar de vraag waar Aldfaer in de procedure was.

Voor de andere onderwerpen zou je een nieuw draadje moeten beginnen.
Onderwerp is gesloten.
  • J.Visser

Re: Database stabiliteit

25 jun 2014 17:00
#1098
Gezien de regelmaat waarmee het is opgetreden acht ik de kans op een onvolledige afsluiting niet zo groot. In mijn twaalf jaar Aldfaer zijn diverse problemen langs gekomen door een onvolledige afsluiting maar niet deze, maar ja eens moet de eerste zijn.
Maar blijf bij mijn opmerking van "buiten de lijntjes kleuren". Om bij afsluiten het oorspronkelijke bestand te behouden moet negatief ( nee) geantwoord worden op de vraag of de wijzigingen behouden moeten worden".
Onderwerp is gesloten.
Gemaakt door Kunena