ROOTSMAGIC-USERS-L Archives
Archiver > ROOTSMAGIC-USERS > 2008-05 > 1211263588
From:
Subject: [RMagic] Reference numbers
Date: Tue, 20 May 2008 02:06:28 EDT
The Newbie Speaks - New to RootsMagic, my first post to the list... (Hi all)
Recently upgraded from FTMaker4 to FTMaker2008...then a friend suggested
RootsMagic. I tried it out and was very pleased!!! (and purchased that as well)
HOWEVER...there are things in my FTMaker4 that are MUCH easier to use than
either of the more modern software. For the moment, I plan to use RootsMagic as
my main software, but there are some clear disadvantages in terms of ease of
data entry...just to add a pair of parents and establish them as married,
include their birth, death, places, children and so on....MAN!!! what a job.
"What WERE they thinking???" However, I love their web site creation routines
pretty much and I'm sure I'll find ways to use it faster.
Now on to the current topic:
The supreme wish list!
If RM uses the same logic as autonumber fields (such as used in MS Access),
the numbers issued at record creation are unique, and are never reused (for
records remaining in the database table)...and when records are deleted, those
numbers become permanently unused numbers (even if the same record data were
reentered). This leaves permanent holes in the numerical sequence that may
be disconcerting to some folks, who wonder where item number 10,007 went to,
etc. However, it serves a purpose in terms of absolute uniqueness. With
genealogy users, who may tend to export/import a lot, in and out of the same
database tables, this can and obviously has led to some frustration about the
number changes occurring...for the autonumbering is not an intelligent style
function. Just remember that when a record gets entered, reentered, or imported
back, it gets a new number...and will not have the number it had before when
residing in that database. Once that idea sinks in, it's easier to fathom what
you will or will not do to track an individual. In Access, I created an
expression that automatically displayed an alpha-numeric code as you entered in
the name, and plugged it into the code field, which as you left the field would
check for duplicates, and let you edit the tail end of the code, adding a
1,2,3, etc., to render it unique...so these things can be addressed, but not
necessarily as easily initially as we'd like. Work-around conventions for
manipulating codes in GEDCOMs is certainly one way, but awfully bug-prone.
What is needed:
Although there may be such an animal out there, the following is a brief
description of what is needed, and a couple ideas about how it could be
accomplished.
Although keystroke recording macro programs could be helpful, which can be
utilized from background-run programs, they can be cumbersome when your input
data keeps changing a lot. Anyway, these are available, and perhaps even as
freeware...I haven't researched it yet. Such a program would likely work okay
with RM, but would be more flexible and easy to use in a software such as
FTMaker4, where many fields are open to use with nothing but a TAB between
fields. The "add fact" function is an example of a biggie standing in the
way...and yet a macro playback can even include dealing with that.
Short of having the following integrated into RM or any other gen software,
what is needed is a preentry program, where you can enter data into (all)
fields in a fell swoop. Creating comma-delimited text files manually to be read
into a table can be error prone. Using a spreadsheet such as MS Excel is a
workable way, and allows macros. Another workable way is to use a database
program such as MS Access, again laying all fields out in a table. My preference
for things of this nature is Access, but I'm sure Excel experts would prefer
that.
Early on things to determine include...assuming you were going to enter all
possible data for a single person, all at one time...including addressing
blank fields for missing data (or data you typically never use), is to determine
what order the data would be entered in the fields. This overall ordering can
be changed, but you want to start out with some comprehensive logic in
place. Once the fields are laid out in that order in a table, you can move from
field to field, leaving fields blank as needed.
Then we look at how you actually would typically enter data, and that may be
several ways that are more often and more common, and some other ways you use
less often. You can set up queries to the table(s) in the (preentry)
database which only show and allow entry into a subset of fields, and ignore and
leave blank the others. You can even create amazingly cool (multiple) data entry
screens to accommodate each of these data entry scenarios, all setup
selectable from a menu. You can assign certain places, surnames, or whatever you
want to each form, or have radio buttons, lists or drop-downs as desired to grab
a particular place or other datum, and yet be able to manually type in one
that isn't being automatically used by the form. Date check verification
across multiple fields can be automated (so you don't have your great grandmother
being born 70 years after her children have passed on, etc.)...and basically
any kind of checking you wish to have, to avoid errors.
You can put places, surnames, or anything else that gets used a lot into
separate tables, which are called upon by the queries and data entry forms to
insert into an individual's record, so that retying them is unnecessary, and
spellings and format remain constant, using the same format for all records as
much as possible (example: for the USA: city, township, county/parish,
state, country...with a separate field for things such as church name, cemetery
name, etc.). That may sound difficult to use, but you can have a places table
setup, for instance, which as you start to type a name, it gives you a set of
choices that match (similar to in a web browser, rather than the type-ahead
used in RM fields), then have it configured so that it checks, and if the
place name you are entering is not in the list, it will ask you if you want to
add a new place name (or retype/reselect, etc.)...which then builds the list as
you go along (important feature is you can delete ones you don't want, or
edit ones already entered). Same for surnames, etc. Anyway, all this and more
make your data entry flexible, easier, faster, and potentially more error
free. Given-name/Surname combinations already existing in the database can warn
you and offer you the existing duplicates to check before contining...allowing
you to change your mind, make a note, etc., or set a "check on this later"
flag which can sort out those records for review later.
So, skipping ahead to make this email readable in a day...
Once your data is in the tables, with a main people table having all the
data (including data that is redundant to the list tables...having been inserted
into fields in the main table from the list table)...then how does one get it
from there into RM or any gen program? Again, this may or may not be
available out there, but what is needed is...
A program that can be configured to handle a wide array of fields in
different ways, depending on how you had them laid out in your main table (above).
If consistent standardized field names are used, then this program (to be
written?) would read the "field names" row, and create a new table as needed with
the fields in the order and format needed for the particular gen software to
be entered into...or into a standard GEDCOM text format (which is probably
better and easier to design and create).
1. If converting your preentry table data into a GEDCOM, then done
deal...import the GEDCOM as usual.
2. If converting for a particular gen program (or with configurations
available for several if writing a full-blown stand alone software), that would get
exponentially more complex.
3. A third way, would be to have a program which worked somewhat like
existing keystroke recording macro program, and it would similarly read and
rearrange the data to the order needed, and utilize a (set of) prerecorded
keystrokes one would need to use if entering a single record manually, including all
data. RM's thing about not allowing a marriage date before the spouse has been
entered as a spouse, complicates things, but surely there would be a way,
without having to manually deal with it.
The way that (3) would work is...
It would read a record for a single individual at a time (possibly even with
relationship fields), and begin doing a predefined sequence of keystroke,
entry, keystroke, entry, etc., until all fields for the person were entered.
What might have taken you 5 minutes to do, would occur in a second or less, with
the gen program dancing, opening dialog boxes, having data entered in
available fields, additional boxes and data, closing boxes, making moves to relate
them to someone else already in the gen program database, at breakneck speed.
It can go fast because you have had the time and visual experience of
keeping your data entered correctly and verified, validated, etc., while doing your
straight-forward data entry. So, this program doesn't need to worry about
those aspects. If there are potential errors which could trigger a gen program
error message, these can be trapped, and the user given options moment to
moment, or the record triggering the error can have the current "record row"
stored in an error log table, and then cancel the error and move on to the next
record, keeping the program flying along, and yet providing you with
problematic record data, and perhaps also including the error code generated by the
gen program.
Now, is there a programmer out there who would like to take on this task? I
might be willing to assist. We can collaborate and create most anything we
want. It is possible to do some things in Access, some things accessing an
existing keystroke recording macro program by coded calls to the program, etc. The
initial work for getting such a project off the ground and to completion
takes some time, some frustration in testing, and other things...but it is
doable, and the end result can be a freebie that really puts the boot to the
behind on many data entry problems. All the better if the end result is even just
the ability to simplify data entry and convert the data to GEDCOM format...a
much more doable project and usable with any gen program.
Some of the elements of the Access programming (programming done internal to
the Access program related to a user-created database) are things I've
already done in Access. My wife, who happens to be retiring within a week
(although not a genealogy buff), is somewhat of an Access guru. The other, more
complicated issues, such as calling external programs, etc., can be done from
Access, but I'm not sure how that goes...but she might. If we have others on the
list with some savvy and the time and willingness to plug their head into the
project, it might actually happen. Best case scenario is not use macro
programs or other programs to address RM or any gen program directly, and just use
Access to setup for creating, and then create GEDCOMs from raw data.
Access forms can be controlled in terms of foreground-text and background
color, etc., on an element by element basis, making it possible to really make
the forms easy to understand, display helpful hints, let you know which field
your cursor is in, and more....
Although I don't believe Access uses keystroke macros (been awhile, have to
check), it does allow certain types of macro routines to be configured, which
would be helpful along the way...say if importing an existing text table
(comma-delimited or other), letting you execute certain functions at the time
you import it, saving manually massaging everything. An example would be as
simple as...once you finish a given preentry table, you could just click a
button to exit, which would do a specialized exit, doing some checks and clean-up
on your data, backing up your last session file to a new filename, saving
your new session file to a standard current session filename (cascading
backups), then exporting your current session file in text (possibly even GEDCOM)
format, before quitting Access. The Access file itself is automatically save
each time you enter a record.
Call me a dreamer. <wink> If none of that made sense to you, be clear you're
not alone. It was a little on the geeky side.
Doug
**************Wondering what's for Dinner Tonight? Get new twists on family
favorites at AOL Food.
(http://food.aol.com/dinner-tonight?NCID=aolfod00030000000001)
This thread: