If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below. |
|
|
Thread Tools | Display Modes |
#1
|
|||
|
|||
Duplicate Fields
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..... |
#2
|
|||
|
|||
Duplicate Fields
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" m wrote in message ... 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..... |
#3
|
|||
|
|||
Duplicate Fields
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" wrote: 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" m wrote in message ... 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..... |
#4
|
|||
|
|||
Duplicate Fields
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" m wrote in message ... 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" wrote: 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" m wrote in message ... 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..... |
#5
|
|||
|
|||
Duplicate Fields
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" m wrote in message ... 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" wrote: 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" m wrote in message ... 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..... |
#6
|
|||
|
|||
Duplicate Fields
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 "Evi" wrote in message ... 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" m wrote in message ... 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" wrote: 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" m wrote in message ... 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..... |
#7
|
|||
|
|||
Duplicate Fields
On Thu, 20 Mar 2008 16:06:01 -0700, Specific User Form Access
m wrote: 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. -- John W. Vinson [MVP] |
#8
|
|||
|
|||
Duplicate Fields
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. "Evi" wrote in message ... 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" m wrote in message ... 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" wrote: 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" m wrote in message ... 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..... |
Thread Tools | |
Display Modes | |
|
|