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

Re: Historical research database

Expand Messages
  • ray_murphy aus
    ... RM: It s just a figure of speech I m using to indicate the electronic record which contains one or more pieces of information about a person in a dedicated
    Message 1 of 32 , Dec 1, 2009
      --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@...> wrote:
      > On 1 Dec 2009 at 16:02, ray_murphy aus wrote:
      > > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@> wrote:
      > > >
      > > > On 30 Nov 2009 at 10:28, ray_murphy aus wrote:
      > >
      > > >>[....] It looks like we need some examples to motivate us.
      > >
      >> >>[....] It looks like we need some examples to motivate us.
      >> >Here is such an example -- a report from the database whose >structure
      >> >(field
      >> >list) I posted a few messages back:
      >> [Snip]
      >> 17-Mar-1853 Orange River Sovereignty, Bloemfontein
      >> People: 1. Green, Fred
      >> 2. St John, William Jones
      >> 3. Dawson, William
      >> 4. de Smidt, Johannes
      >> Sources: 1. St John, Diary, p. 63
      >> 22-Mar-1853 Orange River Sovereignty, Bloemfontein
      >> BAIN
      >> People: 1. Green, Fred
      >> 2. St John, William Jones
      >> 3. Bain, Andrew Hudson
      >> 4. Orpen, Richard John Newenham
      >> Sources: 1. St John Diary, p. 64
      >> 31-May-1853 Orange River Sovereignty, Bloemfontein
      >> MESS
      >> Last mention of Fred Green in St John's diary. On 12 July
      >> St John went on a trip to Harrismith, and returned on 13
      >> August, when the diary ends. Fred Green may have left
      >> Bloemfontein by then.
      >> People: 1. Green, Fred
      >> Sources: 1. St John Diary, p. 79
      >> >Now that is a flat file database, not relational, so the names of the
      >> >people assocated with each event were typed separately into each
      >> > >record.
      >> >That is the kind of duplication that a relational database >can avoid.
      >> RM: That duplication could only be avoided if your MS Access database
      >> was expanded to work like a genealogy program and include file cards
      >> for all the people who are mentioned in the Event-text.
      > I still have no idea what you mean by a "file card". None of my books on
      > MS Access mention such a thing, and none of the experts know what it means
      > either.

      RM: It's just a figure of speech I'm using to indicate the electronic record which contains one or more pieces of information about a person in a dedicated file with a unique code number in either a genealogy program or in MS Access.

      > Byt if you check the diagram I posted at
      > http://hayesgreene.wordpress.com/2009/11/26/370/
      > you can see the main tables and the linking tables
      >> It would also require the manual creation of relationships with the a
      >> huge
      >> array of yet-to-be imagined relationship names - unless they were all
      >> just
      >> called "Event Person" or nothing at all.
      > The person-event link table should show the role of the person at the
      > event,
      > which could be in a lookup table, which the user could edit and add to.

      >> So if Barack Obama II was at a party and you wanted him mentioned,
      >> he would need a file card, and your list of interesting people would look
      >> the
      >> same, but with file card numbers.
      > He would have a record in the "people" table, and a link to the event. And
      > the
      > link could indicate his role at the event as "Host", "Guest", "Master of
      > Ceremonies", "Speaker" or whatever.
      >> People: 1. Green, Fred
      >> 2. Barack Obama II [No. 936]
      >> 3. Bain, Andrew Hudson [No.1137]
      >> 4. Orpen, Richard John Newenham [No 1489]
      >> Sources: 1. St John Diary, p. 64

      RM: Yes, under any system the recording of all people (of interest) needs to be done, so they can be identified correctly.

      >> >The list of events was selected by the search argument "fred w3 >green",
      >> >which means any record that had "fred" within three words of >"green".
      >> RM: There is a risk at the moment of the wrong names being be used if
      >> you rely on the MS Access search-code to find people, so currently all
      >> of the output needs to be proof-read. If however new file cards were made
      >> as
      >> needed when Event-text was being entered, and you nominated the
      >> relationship
      >> between the subject and that person then there would be less risk of
      >> errors,
      >> but errors couldn't be eliminated entirely unless you specified manually
      >> who
      >> you wanted to be included, and that would be best done by clicking on the
      >> name
      >> in a Listbox.
      >> So if you want error free printouts, it seems that the only way to go,
      >> to record events with extra descriptive text, is to:
      >> (1) Click on the subject's name in a Listbox
      >> (2) Click on the Event name from a Listbox (or type in a unique one)
      > But the aim is to be able to print all the events linked to a particular
      > subject (or group of subjects), or all the subjects linked to an event, or
      > series of events.

      RM: A simple search of everyone's events would throw up the events that contained the keywords and store each whole event record, but they would still need to be edited manually to remove all the unwanted material.

      >> (3) Type in the date (or have an error-free date selection system)
      > Dates are one of the chief difficulties in using MS Access on its own, as
      > it can't handle partial dates in date fields.
      > The simplest workaround I can think of is to records dates as yyyy-mm-dd
      > in text fields, which will sort them correctly, and partial dates can be
      > 2009-00-00 or something similar.

      RM: That would work ok.

      >> (4) Paste-in or type the text for the Event.
      >> The first 3 above are already in this little program that I've just
      >> written, and the next 4 could be added.
      >> A relational database cannot find relationships correctly all the time
      >> unless the relationships are set in concrete, and the only way that could
      >> be
      >> done (besides creating file cards for every person you want mentioned) is
      >> to
      >> append the Event-text (from someone's diary etc) with that person's
      >> unique file card number in the database.
      > Again, I'm not sure what you mean by "file card".
      >> For example, instead of the diary text reading:
      >> "Commodore Smith attended the gathering ..."
      >> It could be changed to:
      >> "Commodore Smith [1186] attended the gathering ..."
      >> then when the printout is produced, you have the [1186] automatically
      >> omitted.
      >> The relational database wouldn't care if Commodore Smith was
      >> recorded as "Commodore P.J. Smith, RAN". It only needs his number
      >> to know that he needs to be mentioned as a person of interest at an
      >> event.
      >> I suppose strictly speaking there *IS* no (personal) relationship for a
      >> relational database to find on your behalf. The program merely wants to
      >> know
      >> "Do we print this person or not - as a person worth mentioning every time
      >> the
      >> name pops up in Event-text?" If it sees a number in the Event-text in
      >> brackets, then it knows that the preceding name needs to be added at the
      >> end
      >> of the Event-text. The hard part for the program could be figuring out
      >> where
      >> the name actually began in the text if it wasn't identical to the file
      >> card
      >> name.
      > In a program like MS Access (or other relational database program) it is
      > done by giving each event record a unique key field, and having a link record
      > that links the event record to the person record through the key fields.
      > It doesn't have to look for references in the text field at all. To link
      > them.

      RM: That's what I was saying too, but also that the ID key for each person needs be included in the Event-text next to each name so it can be used.
      If your current system is modified to do that, you won't need to use approximate search arguments like "fred w3 >green", you can simply search for his ID number. If you want to place those ID's in all of the events quickly, just have a sub routine that searches the entire database and swaps a name like:
      "Bill Smith" -- for "Bill Smith [1184].

    • 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.