Separating Activities from Contacts

[Kurt_S]

Greetings,
  I need to separate the Activities table from Contacts to make the calendar available to more than one Contact datafile. (Vendors, clients, etc with separate datafiles).
  Although I can see how this would be difficult (and would involve some loss of functionality), using FM10 and calculated _fk fields based on datafile names I believe I can make this work.
  Does anyone have experience with this sort of Mod? Feedback on some possible Gotchas would be greatly appreciated, along with a real-world example of someone who has already been down this road.

[Chris]

Hi Kurt,

Why do you think there is a need to create new tables, or rather, what are the requirements that necessitate adding new tables?

Personally, I would NOT try to 'break out' vendors and clients from the Contacts table.  Instead, I would stick with the idea that all contacts are Contacts regardless of whether the contact is a vendor, client, employee or user.  Differentiating contacts from each other by their capacity or their relationship to the organization is as simple as setting a field value (perhaps use the Contact::Customer_Type, or a field that you create).  Using this method you will not need to recreate all of the schema for each of the proposed new tables.  It may be easier to grasp this idea if the Contacts table were renamed to Entities instead. 

Let me know what you think.

Chris

[Kurt_S]

Chris,
   Thanks for your prompt reply. Unfortunately, we need to use these tables in distinctly different ways. I don’t have a business reason for keeping vendor information in the same file as client information, for example. I need internal staff info (Resources) for a separate application entirely.  And vendor information, linked to a (separate) Jobs file, will be expanded into a cost-materials system.
   Although I understand that keeping addresses in one big file may work for a basic CRM, we need to go beyond that for this project.  And multiple contact files will break the calendar unless Events are pulled out into a separate file and managed there.
   I am starting this Mod today; any suggestions on "particularly difficult areas" would be appreciated.
   Kurt

[Chris]

Hi Kurt,

I still do not understand the logic behind creating separate tables for entities that are basially the same, and without doing a great amount of research on the foundations and requirements of your project I really cannot help beyond the advice I already gave.

If during your development you have specific problems please post them on this forum and I will be glad to try and answer.

Chris
 

[Gnurps]

Kurt,
Is there some possibility that your need is based more on security than on data relationships? If so, then there is no need to separate the Contacts table. You should use calculated permissions, instead.

I am replying months after your post. If you did create a solution, we might all be interested in knowing what you came up with.

Gary