On 3 Dec 2009 at 19:11, ray_murphy aus wrote:
> --- In firstname.lastname@example.org, "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
> 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
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.
Phone: 083-342-3563 or 012-333-6727