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
|
|||
|
|||
Access 2002 Advice
Hello,
I am in the middle of designing a database for my department and I need some guidance as to how to proceed. I am desiging a form that will be broken down into 13 seperate sections for users to complete, all sections relate to one "account number". What I did was create 13 different tables using the same primary key in each table (ex: account number as PK in each table). Then I tied together each table as a query and started to create the from using the one query as the basis for the form. When I type in the "account number" on the form , all of the tables are updated with the information that corresponds to each section. my question is, will this type of design turn my database into one complete mess? or am I on the right track with how I have designed it to this point? I would like to draw reports off of the entered information and I feel that this design method may screw everything up. I am using windows 2K with office xp |
#2
|
|||
|
|||
Aside from your desire to use 13 separate sections on the form, what
rationale have you used to determine that this must be 13 separate tables, plus a main table? I ask because the standard approach to designing a relational database (Access, SQL Server, Oracle, ...) is to start with the entities (tables) and relationships first, then design forms that make it easy for users. Without more information about how your data is structured, it could be tough to offer (cogent) suggestions... -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... Hello, I am in the middle of designing a database for my department and I need some guidance as to how to proceed. I am desiging a form that will be broken down into 13 seperate sections for users to complete, all sections relate to one "account number". What I did was create 13 different tables using the same primary key in each table (ex: account number as PK in each table). Then I tied together each table as a query and started to create the from using the one query as the basis for the form. When I type in the "account number" on the form , all of the tables are updated with the information that corresponds to each section. my question is, will this type of design turn my database into one complete mess? or am I on the right track with how I have designed it to this point? I would like to draw reports off of the entered information and I feel that this design method may screw everything up. I am using windows 2K with office xp |
#3
|
|||
|
|||
the form that I am trying to create is a file analysis form. There are 13
key sections that the analyst will have to fill out information, or their findings under each of the sections. My line of thinking was to not have the analyst type in the account number, name of account holder, address, etc. over and over on each seperate section, but to combine all sections together and have them type the account information once and only once. the query ties it all together, and for the most part it has worked. My concern is that as the tables get larger, the database will probably get bogged down and get slower and slower. "Jeff Boyce" wrote: Aside from your desire to use 13 separate sections on the form, what rationale have you used to determine that this must be 13 separate tables, plus a main table? I ask because the standard approach to designing a relational database (Access, SQL Server, Oracle, ...) is to start with the entities (tables) and relationships first, then design forms that make it easy for users. Without more information about how your data is structured, it could be tough to offer (cogent) suggestions... -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... Hello, I am in the middle of designing a database for my department and I need some guidance as to how to proceed. I am desiging a form that will be broken down into 13 seperate sections for users to complete, all sections relate to one "account number". What I did was create 13 different tables using the same primary key in each table (ex: account number as PK in each table). Then I tied together each table as a query and started to create the from using the one query as the basis for the form. When I type in the "account number" on the form , all of the tables are updated with the information that corresponds to each section. my question is, will this type of design turn my database into one complete mess? or am I on the right track with how I have designed it to this point? I would like to draw reports off of the entered information and I feel that this design method may screw everything up. I am using windows 2K with office xp |
#4
|
|||
|
|||
Please reconsider my first response. To get the most out of Access, you
need to design and build your system with relationships and normalization in mind. Your rationale seems to say "I have 13 key sections, therefore, I need 13 tables." And one more time ... first design the table structure, then the forms to help the users. If you don't want them to fill out common info before filling out information that is somehow related (?a "section", whatever you mean by that), you can accomplish that in any number of ways in Access. Where's the data?! (think little old lady asking "where's the beef?!") -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... the form that I am trying to create is a file analysis form. There are 13 key sections that the analyst will have to fill out information, or their findings under each of the sections. My line of thinking was to not have the analyst type in the account number, name of account holder, address, etc. over and over on each seperate section, but to combine all sections together and have them type the account information once and only once. the query ties it all together, and for the most part it has worked. My concern is that as the tables get larger, the database will probably get bogged down and get slower and slower. "Jeff Boyce" wrote: Aside from your desire to use 13 separate sections on the form, what rationale have you used to determine that this must be 13 separate tables, plus a main table? I ask because the standard approach to designing a relational database (Access, SQL Server, Oracle, ...) is to start with the entities (tables) and relationships first, then design forms that make it easy for users. Without more information about how your data is structured, it could be tough to offer (cogent) suggestions... -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... Hello, I am in the middle of designing a database for my department and I need some guidance as to how to proceed. I am desiging a form that will be broken down into 13 seperate sections for users to complete, all sections relate to one "account number". What I did was create 13 different tables using the same primary key in each table (ex: account number as PK in each table). Then I tied together each table as a query and started to create the from using the one query as the basis for the form. When I type in the "account number" on the form , all of the tables are updated with the information that corresponds to each section. my question is, will this type of design turn my database into one complete mess? or am I on the right track with how I have designed it to this point? I would like to draw reports off of the entered information and I feel that this design method may screw everything up. I am using windows 2K with office xp |
#5
|
|||
|
|||
My only answer to the rationale is that I am trying to keep my boss happy.
He has developed the form that the analysts will use but has now decided that he wants to track all of the information on a database. The form is broken down into 13 sections for the analysts to review, section A covers one aspect of the file, section b another, and so on. Each section will not relate to the other except for loan number. My line of thinking was to create each of the tables and run a query that would be used for the form they would eventually use. I have not built anything like this before and I hope that your expertise will show me a better way to build this database. thank you for your time. "Jeff Boyce" wrote: Please reconsider my first response. To get the most out of Access, you need to design and build your system with relationships and normalization in mind. Your rationale seems to say "I have 13 key sections, therefore, I need 13 tables." And one more time ... first design the table structure, then the forms to help the users. If you don't want them to fill out common info before filling out information that is somehow related (?a "section", whatever you mean by that), you can accomplish that in any number of ways in Access. Where's the data?! (think little old lady asking "where's the beef?!") -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... the form that I am trying to create is a file analysis form. There are 13 key sections that the analyst will have to fill out information, or their findings under each of the sections. My line of thinking was to not have the analyst type in the account number, name of account holder, address, etc. over and over on each seperate section, but to combine all sections together and have them type the account information once and only once. the query ties it all together, and for the most part it has worked. My concern is that as the tables get larger, the database will probably get bogged down and get slower and slower. "Jeff Boyce" wrote: Aside from your desire to use 13 separate sections on the form, what rationale have you used to determine that this must be 13 separate tables, plus a main table? I ask because the standard approach to designing a relational database (Access, SQL Server, Oracle, ...) is to start with the entities (tables) and relationships first, then design forms that make it easy for users. Without more information about how your data is structured, it could be tough to offer (cogent) suggestions... -- Good luck Jeff Boyce Access MVP "saschamps9903" wrote in message ... Hello, I am in the middle of designing a database for my department and I need some guidance as to how to proceed. I am desiging a form that will be broken down into 13 seperate sections for users to complete, all sections relate to one "account number". What I did was create 13 different tables using the same primary key in each table (ex: account number as PK in each table). Then I tied together each table as a query and started to create the from using the one query as the basis for the form. When I type in the "account number" on the form , all of the tables are updated with the information that corresponds to each section. my question is, will this type of design turn my database into one complete mess? or am I on the right track with how I have designed it to this point? I would like to draw reports off of the entered information and I feel that this design method may screw everything up. I am using windows 2K with office xp |
#6
|
|||
|
|||
"=?Utf-8?B?c2FzY2hhbXBzOTkwMw==?="
wrote in : My only answer to the rationale is that I am trying to keep my boss happy. He has developed the form that the analysts will use but has now decided that he wants to track all of the information on a database. In that case, you have two initial jobs to do: first you have to learn about relational design and the principles of sound databases; then you have to teach them to your boss. When you've done all that, you can start doing the systems analysis and requirements analysis, risk log, etc... Sometimes it's the job #2 that is the hardest! All the best Tim F |
Thread Tools | |
Display Modes | |
|
|
Similar Threads | ||||
Thread | Thread Starter | Forum | Replies | Last Post |
Will Access 97 reports run in Access 2002? | jspanky | Setting Up & Running Reports | 2 | October 5th, 2004 01:27 PM |
Linking Access 97 tables to Access 2002 tables | michaelwoodard | Database Design | 2 | August 13th, 2004 02:43 AM |
Access 2000 DB in Access 2002 | Tony_VBACoder | General Discussion | 2 | July 28th, 2004 01:23 AM |
Merge Access 2002 Runtime Setup With SP3 | Darrel | General Discussion | 10 | July 13th, 2004 07:32 PM |
You do not have exclusive access... ERROR | Robin | General Discussion | 1 | July 6th, 2004 01:18 AM |