Duplicate Fields

[Specific User Form Access]

I am designing a database that requires multiple, separate entries in the
same field. Example: The field may be named "Issue", however they are
assigned different "Incident Numbers" that coorespond to each issue.

How do I duplicate this field??? Do I have to just create individual fields
and provide a unique name such as "Issue", "Issue_1", "Issue_2", etc.....

 

[Jeff Boyce]

It sounds from your description like you are trying to create a ...
spreadsheet!

To make good use of Access' relationally-oriented features/functions, you
need to feed it well-normalized data, not 'sheet data.

Requiring "multiple, separate entries in the same field" is poor database
design ... plan for "one fact/one field".

If "normalization" and "relational database design" are not familiar, plan
to spend some time studying up before proceeding.

Or could you just use a spreadsheet?

Regards

Jeff Boyce
Microsoft Office/Access MVP

"Specific User Form Access"

 

[Specific User Form Access]

The field will be "one fact- One field". It is a paramedic QA issues DB that
is part of a larger DB. Each QA (Quality Assurance) issue is assigned to an
incident number (Response Call). For any given day, there may be mulitple
separate issues, but I need to record them in the DB for future reference.....

 

[Jeff Boyce]

Sorry, based on your description so far I'm not visualizing your situation.

Perhaps one of the other newsgroup readers has worked on something like this
before...

Regards

Jeff Boyce
Microsoft Office/Access MVP


"Specific User Form Access"

 

[Evi]

Uh Oh! It looks like whoever gave you the job, doesn't understand databases
either but has been told (correctly) by someone who does, that they Have To
Use A Database.
You have my sympathy. The thing will be impossible to maintain and the
reports will need to be printed on wallpaper to get all the field names into
them.

You'd think that for something as important as this, they would at least
have payed for a proper db consultant to create this thing but I've worked
in a major public service area which shall be nameless, where an important
tool which clearly should have been a database was run from a spreadsheet
because 'we've always done it this way'. They even called the darn
spreadsheet a database!
Grrr!

If the thing is part of a larger db then there shouldn't be anything for you
to design or change (Heaven forfend!). They should have given you a grid (I
won't dignify it with the name of table!) to fill in so that your data can
be 'appended' to their ghastly desecration. Get back to your bosses and ask
them what they want to do with their mess.

Evi



"Specific User Form Access"

 

[Jeff Boyce]

While I agree with your assessment, I'd probably take a slightly different
tack...

What about the idea of going back to the boss(es) and saying "If we do it
this way, here's the cost and what we can expect to have to deal with. Or,
if we handle it this other way, here's the cost and the pros/cons."?

JOPO (just one person's opinion)

Regards

Jeff Boyce
Microsoft Office/Access MVP

 

[John W. Vinson]

I am designing a database that requires multiple, separate entries in the
same field. Example: The field may be named "Issue", however they are
assigned different "Incident Numbers" that coorespond to each issue.

How do I duplicate this field??? Do I have to just create individual fields
and provide a unique name such as "Issue", "Issue_1", "Issue_2", etc.....

How much control do you have over the structure of this database? It's clear
that you need to *add a new table*.

If each Incident can have many Issues, then you need two tables in a one to
many relationship:

Incidents
IncidentNumber <Primary Key> (don't use blanks in fieldnames)
IncidentTime Date/Time
<other info about the incident as a whole>

IncidentIssues
IssueID <Autonumber Primary Key>
IncidentNumber <link to Incidents>
Issue

This will let you add zero, one, eleven, or 3182 issues for each incident and
have them all in the same field.

 

[BruceM]

It may not be their job to understand database architecture. However, if
the OP was planning to look for another job anyhow your approach may be
worth considering.