- Local time
- Today, 16:06
- Joined
- Feb 28, 2001
- Messages
- 30,158
You accused us of not looking. OK, I looked at the DB. Your only table has essentially an ID, a check box, and ONE FIELD that contains names, some sort or course-related info, and a time slot ALL TOGETHER IN ONE FIELD. This is not how Access works. You have not less than four fields worth of data compressed into the single field in the table I saw in the DB.
You suggest that we aren't helpful. OK, I can see how, from your viewpoint, you would say that. You surely didn't hear what you expected or wanted to hear. But let me explain something to you, and this is NOT intended to be nasty - but it IS intended as a dose of reality. You should understand that I am not reacting to what you built, but to your attitude when we dared comment that there might be some serious structural issues.
You want us to help you fix a database for which there is clear visual evidence that you don't understand Access very well and are thinking along Excel-oriented lines in that design. That actually isn't a sin and it IS correctable - but it requires you to do a bit of work up front. That's the power and the peril of Access. It can do some really impressive things - but the more you want out, the more you have to put in. It is NOT for the faint of heart.
Many of us enjoy working on a reasonably structured DB with a specific problem. What YOU have has SO many problems because of the way it is designed (I refer to the DB, not the spreadsheet) that you would do better to completely start over again - but only after learning about concepts of normalization. What you have violates two of the three rules for "Normal Forms" and might violate the third, though that one is harder to figure out.
What you have asked us to do is fix something that had no chance of working in the state that you presented it.
I sincerely hope you can work with theDBguy because he's good. But you need to develop a thick skin because he is going to have to tear apart what you built. If you let your ego get in the way, you will find difficulty in accepting what I anticipate that he will tell you.
For the record, your spreadsheet is NOT 80% of what you need to do. What you need to do is based on the formal procedures of HOW you use the spreadsheet. You are nowhere near being ready to implement things in Access. But I'm confident in theDBguy's abilities and he won't steer you wrong.
You suggest that we aren't helpful. OK, I can see how, from your viewpoint, you would say that. You surely didn't hear what you expected or wanted to hear. But let me explain something to you, and this is NOT intended to be nasty - but it IS intended as a dose of reality. You should understand that I am not reacting to what you built, but to your attitude when we dared comment that there might be some serious structural issues.
You want us to help you fix a database for which there is clear visual evidence that you don't understand Access very well and are thinking along Excel-oriented lines in that design. That actually isn't a sin and it IS correctable - but it requires you to do a bit of work up front. That's the power and the peril of Access. It can do some really impressive things - but the more you want out, the more you have to put in. It is NOT for the faint of heart.
Many of us enjoy working on a reasonably structured DB with a specific problem. What YOU have has SO many problems because of the way it is designed (I refer to the DB, not the spreadsheet) that you would do better to completely start over again - but only after learning about concepts of normalization. What you have violates two of the three rules for "Normal Forms" and might violate the third, though that one is harder to figure out.
What you have asked us to do is fix something that had no chance of working in the state that you presented it.
I sincerely hope you can work with theDBguy because he's good. But you need to develop a thick skin because he is going to have to tear apart what you built. If you let your ego get in the way, you will find difficulty in accepting what I anticipate that he will tell you.
For the record, your spreadsheet is NOT 80% of what you need to do. What you need to do is based on the formal procedures of HOW you use the spreadsheet. You are nowhere near being ready to implement things in Access. But I'm confident in theDBguy's abilities and he won't steer you wrong.
