Hi John,

Can you help me out by telling me which IDs to use to acheive what i want to do?

I'm adding a 'deliverables' table to this system. This will be designed so that we can add what the physical deliverable is for an appointment (which we're going to call a task for our purposes).

The system will behave as follows:

The user will be able to chose a deliverable from a list of predetermined deliverables for/filtered by a company.
They will add one of the above deliverables to the task - an actual add, not a portal so that if the specs for a deliverable changes, it doesn't retroactively change for a project/appointment already in progress.
Deliverables can be viewed per appointment or per project.

The problem is, i can't figure out which ID is best to connect through.

Thanks,

Lynn

Hey John,

Can you also PM me about some mods I'd like to have done to this system? It might make more sense to have you do them than me.

Thanks,

Lynn

lcurrie wrote:The problem is, i can't figure out which ID is best to connect through.

It sounds like your deliverables table will be related to appointments and will have an appointment ID. It doesn't need a project ID since you can show all the deliverables for a project by looking through that project's appointments. This also makes it easy for you to switch an appointment from one project to another without having to change the project IDs in all the appointment's deliverables.

So deliverables would have a field in them named something like "DelApptID_kf" that would hold the value from ApptID_kprime (the primary key in the deliverable's parent appointment). Viewing deliverables per appointment could be done with a portal on the "Blank" tab of the edit appointment mini window, using a portal to a new table occurrence (TO) of delibverables linked to CalDailyAppointments where ApptID_kprime in CalDailyAppointments was related to DelApptID_kf in the new TO called CalDailyApptDeliverables.

Then to show all the deliverables for a project, you'd link an occurrence of deliverables to "ProjectActivitySimple" calling it something like "ProjectActivitySimpleDeliverables" where ApptID_kprime in ProjectActivitySimple was linked to DelApptID_kf in ProjectActivitySimpleDeliverables.

Hi John,

I must be missing something.

Here are the tables and relationships I've created:
http://mercurymambo.com/clients/seed/Picture5.png

When i go to create the portal, neither the deliverables table or the Del2ApptConnector table show up as tables that are related to the CalDailyAppointments.

Thanks,

Lynn

Looks good Lynn. You've drawn a nice join between Appointments and Deliverables. This will work to let you draw a portal of an appointment's deliverables on any layout based on the Appointments 2 table occurrence (TO).

And I think that is the problem. If you want to add this portal to any of the existing layouts, you'll need to move DelToApptConnector and Deliverables to the right of one of the existing appointments TOs instead of connecting them to Appointments 2.

The most likely candidate for this is CalDailyAppointments since that is the TO most of our appointments layouts are based on.

(To get a quick overview of the TO-to-Layout mapping, enter layout mode and select "Set Layout Order" from the Layouts menu.)

And thanks very much for the screen shot- you obviously know how much easier that makes everything.

And I think that is the problem. If you want to add this portal to any of the existing layouts, you'll need to move DelToApptConnector and Deliverables to the right of one of the existing appointments TOs instead of connecting them to Appointments 2.

Ahhhh. That's the basic understanding I was missing. I was under the impression that when i created 'Appointments 2' i was creating an alias to 'Appointments.'

Thanks for clearing that up,

Lynn