I use filemaker for an advertising sales database. I have one database of people that I sell to in the education market, another of people that i sell to in Manufacturing another for gardening etc etc

All the databases work in the same way and just have different records in for each different subject.

My problem is that I have quite a few clients that go into more than one database and buy things from us in more than one subject area. My salesmen cannot tell when selling for instance gardening advertising to them that they have just placed an order in hospitality etc

Is it possible that when a saleman flags something in one database that filemaker could hunt for that same company in all the other databases and insert something in there to say they have a booking in that other database.

Hope that makes sense any help would be much appreciated.

What you really need to do is not have separate files with duplicate entries for a single client. A structure with a client file (each client entered once) and a sales file (with one entry for each product they buy) would make more sense.

-bd

Thanks for the reply, but my company does not want to have one huge database for everyone, mainly because of the worry of people overwriting things when they shouldn't (I know i can prevent that but can't get that through to them)if there was someway of copy data from one database to another one that would be great.

My feeling is that it is part of your job, as a database developer, to prevent them from this kind of thinking. Either steer them away from this kind of thinking in the first place, or get them out of the business of describing "HOW" a database internally should work.

You WILL run into major problems down the road with the functionality that they want. I have seen it everytime. In good conscious I cannot advise you on how to do this.

I've got to agree with Kurt. There's a big difference between what a client/boss thinks he wants, and what he really wants. If someone tells you what functionality they want, it should end there, and the implementation of that functionality should be up to you. The problem you're encountering is akin to that of a garage mechanic being told by a customer how to fix their car. They can't tell you HOW to do it - they're not the mechanic!

A single file with all customers (plus related files for orders, etc.) is the only way to go, in your case. Anyone who tells you otherwise does not understand databases.

-Stanley