[AccessD] Logic issue

On second thought, I would not use a Persons table since the defendant and
or claimant could be a corporation. I would go with tblEntities which might
be tied to a tblEntityTypes table containing such rows as Person,
Corporation, NGO, etc. A given case could for example be a class action
suit, with one or more corporations defending their alleged malfeasance
against hundreds or thousands of claimants (some corporate, some
individuals).

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Arthur Fuller
Sent: August 25, 2005 8:08 AM
To: 'Access Developers discussion and problem solving'
Subject: RE: [AccessD] Logic issue

I agree with Drew but I would take the idea a little further, adding an
associative (bridge) table tblPersonRoles, allowing a many-to-many
relationship between Persons and Roles. I would also add a date range to the
tblPersonRoles table, so that I could note that Person X was a prosecutor
until 1999, when she became a judge, and then in 2004 she was charged with
drunk driving and became a defendant.

-----Original Message-----
From: accessd-bounces at databaseadvisors.com
[mailto:accessd-bounces at databaseadvisors.com] On Behalf Of DWUTKA at marlow.com
Sent: August 24, 2005 2:16 PM
To: accessd at databaseadvisors.com
Subject: RE: [AccessD] Logic issue

I think you need to have a 'people' table.  Whether a person is a judge,
lawyer, defendant should be determined by relationships to the tables
relating to those designations.

Drew

-----Original Message-----
From: John Clark [mailto:John.Clark at niagaracounty.com]
Sent: Wednesday, August 24, 2005 12:36 PM
To: accessd at databaseadvisors.com
Subject: [AccessD] Logic issue


Hi all

I am having trouble working out how I want to go about something, and I
am hoping somebody here can give me a nudge. It doesn't sound difficult,
but I'm running into dead-ends. I am starting to think that I will just
have to go ahead and finish up with "whatever" and work around things.

I am doing a project for a district attorney's office, and it will
basically just keep tabs on everybody that passes through the system.
The problem is though that there are "Defendants", defense lawyers,
prosecuting lawyers, judges, and victims, and it isn't rare for a single
person to cross into multiple lists. And, theoretically, it is possible
to be in all lists. For instance there are many prosecuting lawyers that
become defense attorneys, and it is not unlikely that one of these
attorneys could be a judge in the future. That scenario is very
possible, and you can add it that a lawyer is very able to be a victim,
and hell, we all know they can be criminals ;) Another scenario that
happens very frequently, is that a person is both a defendant and a
victim. 

I don't want the person entering data to scroll through hundreds, and
eventually thousands, of names to pick an attorney's name from among the
list of everybody else in the system.

The idea I am working on presently is to add logical fields for each
designation to the table of names. For instances:

kNameID
txtLastName
txtFirstName
txtMI
txtSuffix
logAttorney
logADA
logJudge
logVictim
logDefendant

If I do this, I will have removed some fields that are currently there,
such as:

txtAddress1
txtAddress2
txtCity
txtSt
txtZip
txtPhone

And, I will put these in another linked table. There may be a need to
have multiple addresses for the defendants, so this would be best I
think.

The problem that I am foreseeing here...I'm not at that point, so my
fears could be unfounded...is setting these fields to true and/or false,
as needed.  Basically, thinking of victims for a minute here, the
defendant screen, which will actually be an "Indictment" screen, will
have a subform to hold potentially many victims for the indictment. If a
victim IS already in the system as something else, I will need to tag
that name as a victim and I'm wondering if this will present
difficulties.

Well, I hope I am being clear enough. If anyone out there has any tips
for me, I would greatly appreciate it if you would pass them along.

Thank you!

John W Clark
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com
-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com

-- 
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com