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

Re: [gensoft] Re: Historical research database

Expand Messages
  • Steve Hayes
    ... I repeat: I would prefer to do it the other way round -- develop a working model in MS Access, THEN write a program in VB or some other language. ... (3)
    Message 1 of 32 , Dec 5, 2009
    • 0 Attachment
      On 3 Dec 2009 at 19:11, ray_murphy aus wrote:

      > --- In gensoft@yahoogroups.com, "Steve Hayes" <hayesstw@...> wrote:

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

      I repeat: I would prefer to do it the other way round -- develop a working
      model in MS Access, THEN write a program in VB or some other language.

      > > At the moment, we're trying to establish and clarify what is required.
      > > 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
      > here.
      > 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 subject.

      (3) All the event's subjects - ie all the people involved in the event.
      (4) All events of a particular type, eith all the people involved in them
      (5) Events relating to anyone who was a member of a particular group or
      organisation.

      And there are several other possibilities.

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

      ALL events should be global, and EACH event should have its own ID number.

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

      The Inmagic program I'm using now allows for the storage of almost unlimited
      text in any field in any record (there is a limit, imposed by disk space). My
      diary takes 40 Megs.

      Relational databases have "Memo" fields or something similar for storing
      large amounts of text.


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

        [....]

        [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"

        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.

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