Loading ...
Sorry, an error occurred while loading the content.

Re: [gensoft] Re: Historical research database

Expand Messages
  • Steve Hayes
    ... My idea was precisely the opposite. First to do a prototype in MS Access or a similar general database program, in order to establish which tables need to
    Message 1 of 32 , Dec 3, 2009
      On 3 Dec 2009 at 11:03, ray_murphy aus wrote:

      > RM: I think most people using relational databases would find it a bit hard to
      > visualise all the connections once they start getting a bit complex, but there
      > could be an easier way to test out some ideas - simply write ordinary code in
      > Visual Basic to tell the program where to go to retrieve the required
      > information and where to add it. That's all MS Access is doing anyway -
      > sending a long set of instructions in relatively plain English - so if we can
      > begin thinking in those terms instead of staring at MS Access graphical
      > representations of the instructions and trying to imagine what goes where - or
      > wondering why we cannot get Access cannot do a particular thing.
      > So if a prototype in VB can be made to work, then it's just a matter of
      > translating the VB written instructions into MS Access mouse clicks etc., and
      > if that doesn't work, just use the slower VB code in partnership with Access.

      My idea was precisely the opposite.

      First to do a prototype in MS Access or a similar general database program,
      in order to establish which tables need to be used, and what links need to be
      made between them.

      THEN, when it's working, and a few people have tried it, write a program in
      Visual Basic or some other language to enter, access and manipulate the data
      in the tables in a stand-alone program that can be used without having to own
      a proprietary one like MS Access.

      I don't know enough about programming to do any of this.

      I could, just possibly, have done it in Paradox 4.5 for DOS 15 years ago, but
      that is obsolete and I've given up trying to keep up. That's why I was hoping
      that people here could do it as a cooperative project.

      > >A report
      > > from that database gives more information on the source as follows:
      > >
      > > Schoeman, Karel. 1988. The Bloemfontein diary of Lieut W.J. St
      > > John. Cape Town: Human & Rosseau.
      > > ISBN: 0-7981-2243-9
      > > William Jones St John was an officer of the
      > > Royal Artillery stationed in Bloemfontein
      > > during the time of the Orange River
      > > Sovereignty. he had a lot of time on his
      > > hands, and spent most of it hunting. Charles
      > > and Fred Green were in town early in 1853, and
      > > he hunted and played billiards with them, and
      > > with Arthur and Henry Green as well, spending
      > > a lot of time with Andreww Hudson Bain.
      > >
      > > In a relational database, it would be possible to include both in the same
      > > report, because "Source" and "Event" would be two linked tables in the same
      > > database. In a "flat file" database like Inmagic, there are no links between
      > > them except in the researcher's mind. The Inmagic database I have created
      > > is useful, but I'm trying to think of ways of making it more useful, and
      > > that can be done using a relational database.
      > RM: I can see no reason why anything like that cannot be done in VB,
      > once the programmer knows what is required.

      Of course.

      At the moment, we're trying to establish and clarify what is required.

      > > So I'm not looking for different ways of searching for records in
      > > Inmagic -- "fred w3 green" works just fine, and there are plenty of
      > > other ways of searching.
      > >
      > > What I'm looking for, and what I think would be useful to other
      > > researchers as well, is a way of linking these different kinds of
      > > information
      > > in a relational database.
      > RM: It boils down to explaining in very clear language what you want a
      > *program* to do - not what you want a relational database to do. Some
      > or all of the work might be done more easily ~outside~ of a relational
      > database - or even outside of MS Access altogether. In some cases a
      > sophisticated relational database would work 100 times faster than VB
      > but hey, will genealogy people be complaining if they have to wait for
      > 1000 milliseconds instead of waiting only 10 milliseconds for something to pop
      > into view?

      The program manipulates the database.

      But before you decide what the program should do, you need to decide on the
      database that you want it to manupulate.

      I have three or four databases I use in Inmagic -- but they are flat file
      databases and so unlinked. Inmagic doesn't do relational databases.

      You can write a program in Visual Basic that does relational databases, and
      you can create and manipulate relational databases with MS Access and several
      other programs. But the database needs to be relational. If it isn't, I might
      as well go on using Inmagic, and that would be of no use to other people,
      unless they too bought InMagic, or its Windows version, DB Text.

      > > What I think we ought to discuss is what kind of information should be
      > > stored, and where and how should it be stored, to make it most useful to
      > > most users.
      > RM: From my experience with a similar project, I'd say that there should be no
      > limit on what kind of information is eventually stored on anyone's program.
      > Besides being a good idea, it completely eliminates arguments and resulting
      > hold-ups.
      > The question of where information should be stored depends on the program
      > design, or whether there are both personal-use databases, as well as large
      > industrial-strength databases. Smaller amounts of data could be stored in
      > simple csv files, and large amounts in MS Access or separate csv files that
      > are called when needed.

      CSV files are flat-file type databases, and sequential access. They can be
      used by very simple programs, but if you want to do anything with them it's
      better to import them into a spreadsheet or a proper database program.

      > > The examples I gave show (I hope) how such a database would be useful to:
      > >
      > > 1. Someone writing a biography of Fred Green
      > > 2. Someone writing a history of the Green family
      > > 3. Someone writing a history of the Orange River Sovereignty
      > > 4. Someone writing a regimental history of the Royal Artillery
      > >
      > > and that's just a few possible uses.
      > Another obvious one, is geneology people simply looking at such a printout for
      > an individual and searching for clues in the text that fit in with other
      > people or events.

      Yes, indeed. You see that you have information on what your subject was doing
      in one period, but not in another, so you ask what went in in the missing
      period. You see that he had a lot of contact with someone in one period, but
      it stopped -- what happened -- did they fall out, go separate ways, or did
      one of them die?

      Steve Hayes
      E-mail: shayes@...
      Web: http://hayesfam.bravehost.com/stevesig.htm
      Blog: http://methodius.blogspot.com
      Phone: 083-342-3563 or 012-333-6727
      Fax: 086-548-2525
    • ray_murphy aus
      ... [....] ... [....] [Update] A much better version of the VB program has been uploaded to the Files section of this group s website. It s called GENEVENTS2
      Message 32 of 32 , Dec 12, 2009
        --- In gensoft@yahoogroups.com, "ray_murphy aus" <raymurph@...> wrote:
        > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@> wrote:
        > >
        > > On 3 Dec 2009 at 19:11, ray_murphy aus wrote:
        > >
        > > > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@> wrote:
        > >

        > RM: I've already got that test VB program working and displaying all the required events, sources and people, but as it turned out, it didn't need MS Access or its complex linkage system at all.
        > The user-interface being used would be the same under any system,
        > and irrespective of what was happening in the background with tables,
        > linkages or arrays.



        A much better version of the VB program has been uploaded to the Files section of this group's website. It's called "GENEVENTS2"

        It can be used to store literally anything that one could ever imagine because users can add their own categories for Events, Facts or Relationships between people.

        Any date system can be used, but if full automatic sorting is required for print-outs, then we need to use the YYYY,MM,DD format. If however some dates are not in the correct format (and order in a printout) then they can be simply re-positioned by Copy/Paste in the print-out panel.

        If "Connected People" are required for event descriptions, then just click on their names and they will be automatically inserted.

        If Sources of information are required for events etc, then they simply need to be entered with the event.

        The program has a concise Help section in the Menu, so most questions will be answered there.

        This latest version should make it easy for anyone to create a database with a SUITABLE 5.5 Gedcom and start seeing future potential or current weaknesses with the system.

      Your message has been successfully submitted and would be delivered to recipients shortly.