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

Re: Historical research database

Expand Messages
  • ray_murphy aus
    ... RM: It would be quite easy for a skilled MS Access programmer to do what you re looking for, but only if very clear instructions were given beforehand.
    Message 1 of 32 , Dec 3, 2009
      --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@...> wrote:
      > 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.

      RM: It would be quite easy for a skilled MS Access programmer to do
      what you're looking for, but only if very clear instructions were given
      beforehand. Most of those who could volunteer to help would be saying
      that they were only available to write the code from clear instructions -
      not *develop* a good program over a period of several weeks or many
      months - so a working model in VB or anything else would make it
      very clear to them if you said:-
      "Do what that program is doing, but more efficiently"
      It would remove nearly all of the inevitable string of
      misunderstandings that programmers constantly face.

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

      RM: It seems we might be talking about some pretty simple relationships
      What are we looking for - in plain English?
      A printout of:
      (1) All the subject's Events and accompanying text - (easy to do right now)
      (2) All other Event paragraphs in the database that mention the

      * Note(1): Sources could be automatically included at the end of the Event text, so there would be no need to have them at other locations, with links provided to locate and insert them. This would be easy to do, by searching every event in the database for the selected keywords or ID numbers.

      * Note (2): Global events could all be stored as just that - for an entity named "GLOBAL" with its own ID number.

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

      RM: Only if a database is very big. I use a csv file for most of the prominent people (to the western world) ever born in history, in a csv database of 30,000 people. Sure, it takes a minute or two to load, on a 300Mhz PC but once it's loaded the data is recalled extremely fast and events of every imaginable description are added in a flash.
      Mind you, the event descriptions are small - unlike your longer diary entries etc, but the average genealogy person is unlikely to be keying-in or pasting-in mountains of text - so this is all 'do-able' in the very near future - and it's when people have got something that actually works, they can suggest improvements.


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