There is a database where entries are added from a big paper file. It's
core is persons in one table with id's auto-generated and their
actions in another related table likewise auto-generated id's. Now it
seems there was two or more persons availale for data entry. But is it
possible to split this work for simultaneous data entry and combine the
resulting databases later? Any examples?

In article <4ac253af$0$26310$9b536df3 (AT) news (DOT) fv.fi>,
jife <no (AT) email (DOT) please> wrote:

Set up a FileMaker network, with the database on one computer as host,
and others operating on that database. Then all the data entered by
multiple users is going into the same host database.

Can also do this with Instant Web Publishing, so all the others don't
have to have copies of FIleMaker.

See the Filemaker Help about sharing your database.

"jife" <no (AT) email (DOT) please> wrote

In an ideal world, the paper file is well organised so that all the
information for each person is together, then one data entry person could
start at the beginning while another data entry person starts from the end,
and there will be no overlap or double entry problems.

Unfortunately, since this is the real world, and the paper file is likely to
be one large mess of double-ups and have information scattered troughout it,
which means no matter what you do in the data entry, you going to have to go
back and do some tidy up.

For the actual data entry, you can either:
- run the database on a server or hosted on one computer,
and accessed by the other computer at the sam time,
(This way can help with double-up data entry if the users
perform a Find to see if the person already exists before
plowing on to enter the data.)
or
- run two copies of the database, one on each data entry
person's computer, and then import the data from set
into the other (after making backups of both!!).

Helpfull Harry )

Your Name wrote:
Thanks for realistic views,
actually we have FP Pro's and separate workstations available. And
probably the persons would be working partly different times w/o
network connection.Your second suggestion: Is the combination of
separate parts of work possible. The auto-generated id:s bother me -
what kind of code would be necessary to unify the final database?

In article <4ac27ac4$0$26345$9b536df3 (AT) news (DOT) fv.fi>,
jife <no (AT) email (DOT) please> wrote:

1. It is very easy to set up FileMaker network sharing. All you need is
one computer with FileMaker and the database installed, and one or more
other computers connected by way of a local network, each running its
own copy of FileMaker Pro. Then the others log on to the shared database
and work on it exactly as if it were running locally on each computer,
but they are all actually working on the same database. No need to do
any import of data afterward.

However, each computer must have its own licensed copy of FileMaker.
FileMaker is smart enough to look for duplicate license keys on the
network, and prevent the duplicate licenses from logging on.

Also, the versions of FileMaker on the various computers have to be
compatible. If the host is running FileMaker 7, 8 or 9, the client
machines can be running 7, 8, 9, or 10. FileMaker Inc. says if the host
is running FileMaker 10, then FileMaker 7 may not work reliably with it.

If the host is running earlier versions of FileMaker, then the clients
must also be running the earlier version. 5 & 6 are compatible with each
other, but not with 7/8/9/10, and not with 3 or 4.

Using Instant Web Publishing (IWP), you can enable computers that don't
have FileMaker installed to log on and do data entry using a web
browser. IWP is pretty smooth with the host running FileMaker 7/8/9/10,
but pretty clunky with the host running earlier versions.

These are both very easy to do. Look in FileMaker Help, as I said
earlier, to find out about FileMaker network sharing and Instant Web
Publishing.

2. Helpful Harry's suggestion of two copies of the database running
separately will work. The ability to import data from one to the other
is built in to FileMaker. Look in the FileMaker help to learn about
importing data.

3. Helpful Harry's comment about the likelihood of getting duplicate
data entered from old paper records is entirely valid.

"jife" <no (AT) email (DOT) please> wrote

The best thing would be to set-up the two separate databases to use
different ID codes (e.g. one person has codes A1, A2, A3, etc. and the other
has codes Z1, Z2, Z3, etc.). Then you can happily import the data from one
database into the other without having conflicting codes.

When you're doing the importing (make backups of all the files first in case
it goes wrong!) just remember to turn OFF the option to do the auto-enter
options so that it keeps the imported codes rather than creating new ones
(which would be then mismatched with the related data). Then it's just a
matter of importing the records from one set of files into the appropriate
tables of the other.

Helpfull Harry )