Jump to content

blissland

Members
  • Content Count

    121
  • Joined

  • Last visited

Community Reputation

0 Neutral

About blissland

  • Rank
    member

Profile Information

  • Title
    School Director
  • Industry
    Education
  • Gender
    Male
  • Location
    Hawaii

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I have a few different pictures of what you're suggesting, so just to be clear.... Are you saying that I make a new field, populate it with what's in the old field, and then convert the new field to a lookup field from that point forward (and then just remove the old field)? Or are you saying that I create a new field that always enters the values of the old field but unlike the old field is editable? I think you're saying the former.
  2. I'm wondering how to set fields up so that the prices for items purchased will fill in the COST field when the items are selected while at the same time having the option to fill in an alternate price. So if I indicate that Customer 1 selects Item A, the cost will fill in with $100 as I've pre-specified elsewhere for that item, but I could go in and make it $80 for one customer. Currently if I go in and alter the price in that customer's record, it also changes the price for that item for everyone who has bought that item, because it's a calculation field. But if I change it to a lookup fie
  3. I have a Status field in the table where I specify in what stage of the enrollment process (from first contact to graduating) the person is in. I also have fields to remind me whether I emailed them or called them or need to call them back. I filter by the Status field to show me in one layout a list of everyone who has contacted me or in other layouts just those who have applied or are enrolled or have graduated. But now it occurs to me that filtering by this field is not as effective as having a Person-Class join table for everyone that's enrolled in that class. This is simple enough, bu
  4. The lookup that you showed me here is so easy. If I go back and convert all of my item-price calculation fields into lookup fields, will it keep the same values that are there right now (all values the calc uses are still the same)? If the values used in the calculation were not the same, would it keep the same result or would it look it up once more when I make it a lookup field? The summary field is great. So simple I'm embarrassed that I didn't know about the Count option. Thank you. So, what's the pros or cons of keeping all the purchases in one table (and populating the fields w
  5. The attached ERD is updated. The star objects represent the "many" side of the relationships. I'm very confused as to how the StudentPackages (Enrollment) relates to StudentPurchases. Doesn't feel right to me, but no idea what to do about it.
  6. Yes, I think students enroll in Packages, not classes. If I am including electives in this, which I think makes sense to do, then each elective is a class, and it just gets copied across as it's own package so that I'm only selecting packages and not both packages and classes. Students currently don't enroll in multiple programs, but if I'm counting electives as their own packages, then they absolutely could enroll in multiple ones. If each package is going to include various combos of classes, then I would think a join table would be necessary to specify which classes go into w
  7. yes, i think that's it. so would that look like this: Students----Enrollments----Packages----PackageClassJoin---Classes And I think payment plans would just be another "package" that they enroll in (which I guess wouldn't have a class associated with it). Is that correct or is there a table missing? In a standard Customers--Invoices--LineItems--Products arrangement, customers is like students, packages is like products, and enrollments is like....? Also, given that the "price" field would be in the Packages table. would I just change the price fields as they change or w
  8. If I am counting electives, then the answer is definitely many (the main one plus a handful of electives). If I am not counting electives, then I would normally say ONE (the main 6 month class that happens each year). However, for marketing purposes I created three Tuition Packages. Package B is the ONE regular 6-month program. Package A is this one program plus an elective at a discounted rate. Package C is an auditing option for the occasional student who can't attend every portion of the Package B program. I think of this as being ONE program with variations. However f
  9. I apologize for not describing everything as clearly as I should. When I said "each class has it's own unique packages" I was using the word 'class' to refer to the 'year', as in "the class of 2015". All the students in the "class" of 2015 are all enrolled in the same 6-month "class". I should have said that each YEAR has it's own packages and payment plans (though even that statement might not technically be correct). There has always been a 1-to-1 relationship between year and class historically, so I confuse them easily. I'm going to take some time to rethink the logic of this so I can
  10. Thanks for this. I think your diagram is accurate for most school programs, though I'm not entirely clear about why classes relates to so many objects. I think my ideal schematic might be slightly different. My bad for not describing the situation well enough. When I started this database, there was just one 6-month program that students signed up for. So all I needed to do was track enrollment and payments, and then on the side I kept track of an occasional weekend elective class and some purchases (books, etc). The Class table was only about the main program, not about electives.
  11. OK, I get it. The attached file shows how I think that would be incorporated. If I were to put all the workshops and books and supplies in one table, I could also put the TuititionPackages and the PaymentPlans in that same table as well, where each tuition package and each payment plan is an item to purchase. I don't think it should matter that the latter two has a one-to-one relationship with students while workshop/books/supplies can have a one-to-many. they'll just be one item in the table for packages and one item for payment plans. I would also have to move all the fields in the Stud
  12. a student can only have one package and one payment plan per year. There is no Year table. There is a class table, but it doesn't have a StudentID field in it since it's about class-related data that is true across all students. Did you mean the Class table or did you mean I should create a Year table?
  13. That was very helpful. Thank you. Is there a downside to splitting them into two (cuz that's what I ended up doing tonight). If there's a downside I'll redo it. I've never used the Lookup before, and I've had a hard time grasping which to use, even after reading many threads on it. Regarding the summary field, I understand the concept but not the implementation. Does it require a script or some extra TO relationships? I have used basic summary fields, but how would I use it to select only certain items? I think I'm missing one key concept to grasp how it's done.
  14. This is a different question than the one I posted earlier today. I run a school. Each year there is a different class, and each class has it's own unique packages and payment plans associated with it. Each student can only be in one class and can only choose one package and one payment plan. I have the following tables: Students, Class, Packages, PaymentPlans. There are no many-to-many relationships between these. The students table has fields for the PackagesID and the PaymentPlansID. Currently I have the Packages and PaymentPlan tables relating to the Students Table through
  15. I run a school and keep track of everything school-related in an FMP12 DB on Mac OS 10.11. I used to be more immersed in FMP, but now I'm a bit rusty with some of the logic. Last year I kept track of all non-tuition expenses (books, supplies, elective courses) in one table (ItemPurchasers), and that was sufficient for manually tracking what each student owed. But it didn't allow me to easily see at a glance which students ordered Item X or signed up for Elective Y. ItemPurchasers was not a join table since I did not keep a table of Items to select from (hence the manual aspect). So
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.