I'm not sure which section is best for this question...but it deals with relationships...so here it goes:

I have a FileMaker solution out there in the marketplace. I have another solution I'm preparing to release. Both solutions have employee tables. I'm looking for an elegant way of having my new solution utilize the employee table of my current solution IF the customer has the first solution...otherwise it should use its own employee table.

Anyone have any experience with this sort of situation?

I don't really think there is a way to do this, and besides I can see the potential for mischief later: there could be records in either employees table if the first file ever becomes unavailable (or becomes available).

I'd re-think the strategy. Perhaps change the first solution to have a separate Employees file that can be shared between both.

Would it not be easier to give the new solution the ability to import the old employees data into the data structure of the new solution? This way it becomes a once-off exercise and the old solution can be archived.

This might also give you the opportunity to develop the new solution as a separation model, so that any future upgrades to the solution can use the same data file immediately.

I'm not sure I understand what you mean by 'separation model' ... you mean breaking out certain (or all) tables into their own files like older versions of FileMaker required?

I suppose I could update the current solution by separating the tables that will be shared...I guess I'd just be concerned about someone downloading and installing the new solution replacing the shared files with the empty ones that would need to be included in the new solution. Perhaps some form of installer script would help dummy proof it.

By separation model, I mean that all the scripting and layouts are in one file - and all the actual data is in a separate file.

This means that the code file can be replaced with a new version without having to go through any import or export processes.

See here for more information:

http://fmforums.com/forum/showforum.php?fid/20/keyword/separation/

Brian

By separation model, I mean that all the scripting and layouts are in one file - and all the actual data is in a separate file.

That is what the separation model attempts to do, but it's not quite as clean cut as that. The relationships have to be built in both interface and data files and maintained accordingly. Stuff doesn't always "just work" like it used to.

IMHO it's in the same category as anchor-buoy: a great idea in theory but not nearly as useful in practice as the theory would suggest.