Possibly not, but then I don't know what you want to see in your calendar.
Do you want to see both entered dates and due dates in the same box in a single list?
You may need to create a secondary table of dates where one record is either an "entered" date or a "Due" date for a given record in your orders table. When you enter a date on your orders layout a pair of relationships, one for each file can be set up so that you are actually creating a related record in this table where you then enter the date. Since this is now a unified table of date records, you can then display these dates in portals where each portal displays all the date records for that day, both "entered" and "due" dates combined.
If you are interested in examining a simplified calendar demo file:
Thank you, good question. I do not need to see them on the same list, but I do need to see them on the same day. My calendar view will most likely be a single day (as opposed to a month). On that day record I need only to see a list for those entered today and a list for those due today. Does this scenario require a separate table for each date type?
It depends on what you want to see. To get a list that looks like the following, you'd need a common table:
Order #: Type
I think, though, you'd want this type of layout setup:
That's really two separate lists for the same date. With that layout design, you could place two portals on your layout, that each use different relationships to link to your orders table. One relationship would link by the "entered" date field and the other by the "Date due" field.
I do prefer the latter. Here's where I'm having trouble. I currently have a dates table and it auto populates each day to add the current day to the table. This table relates back to the orders table with a relationhiop of ENTERED DATE --> CALENDAR DATE. This relationship works fine and I can view records and summarize data for the ENTERED DATE. When I tried though to add second relationship for the field DUE DATE, it allowed me to do so (I had to create the second....I guess it's a dummy table called "Calendar 2"), but no records appear in the portal.
Perhaps I have the portal configured incorrectly? Currently it is set to view records from the ORDERS table with the filter defined as ORDERS::DUE DATE = CALENDAR2::DATE
You need to turn things around here, since I assume your layout is based on Calendar. You need one ocurrence for calendar and two for Orders so that you can link two the two date fields in Orders from the same record in Calendar.
Calendar::Date = OrdersByDateEntered::DateEntered
Calendar::Date = OrdersByDateDue::DateDue
You can then place portals to OrdersByDateEntered and to OrdersByDateDue on your Calendar layout to display the two lists of records from the Orders table. To rename a table occurrence from Orders 2 to OrdersByDateEntered, double click it. (Note: If you need to add fields from tables related to orders inside your portal, you'll need to create additional table occurrences for them and link separate occurrences of them to both OrdersByDateEntered and OrdersByDateDue.)
If Table Occurrence is a new concept, you might want to read this tutorial:
wow, thank you Phil. That was damned easy. The portal is working fine now. Why is it that I had to flip it like that?
Portals work from the values of the current record of your layout and that current record is controlled by the Table Occurrence, Calendar, that you specified for your layout in Layout Setup|Show Records From. Since you needed two lists of orders records for the same record in Calendar, your relationships needed to start with a common record in Calendar and then link to different sets of records in each portal--which in turn needed to be different table occurrences of orders.
You may find that easier to understand after playing around with the tutorial I suggested. It's designed to both explain Table Occurrences and also to illustrate how they, in turn control the function of nearly every asplect of your database. There's also a few "tricks of the trade" demo'd along the way...
Thank you again Phil. You've been most helpful.