Newbies Anders Stockholm Posted November 21, 2006 Newbies Posted November 21, 2006 Hi! 2 hours without finding an answer with Search. My problem is probably VERY simple, but I´m STUCK. I´m developing a telemarketing applikation for my own company. I need to export records from a file/table with PEOPLE and their ORGANISATION (=job) to a a PROJECT/CAMPAIN file/table which can have the same person many times belonging to different CAMPAINS. Each of my customers can have different CAMPAINs targeting different groups of people. I´ve tried to build this with relations but without success, because each PERSONs record needs a unique ID for the CAMPAIN record (where I keep my notes and keep track of all calls I?ve done), which he/she "belongs to". I?ve tried every scriptvariation I could find without success. If anyone understands what I´m trying to say, please answer. Best regards from Stockholm and Anders Söderman
Søren Dyhr Posted November 21, 2006 Posted November 21, 2006 It seems like many persons can be the target of many campains, so the structure is a many to many. The need for exporting records should be used for what? Which can't take place inside a relational solution given the right set of layouts work with? --sd
Newbies Anders Stockholm Posted November 21, 2006 Author Newbies Posted November 21, 2006 Thanks Sören. " The need for exporting records should be used for what? ": I want to extract selected people (a few to hundreds) , from my large database of people in the GIS-business to a table connected to a specific CAMPAIN. One of my customers can have many CAMPAINS and I have many customers. I also need to keep track of which persons I have contacted before in other CAMPAINS, which is difficult. My problem before was that I had to have one field in the persons record with the CAMPAIN_ID for every CAMPAIN that the person belonged to and I couldn´t solve that. Thats why I want to export records to a table inside the CAMPAIN file. I have on CAMPAIN file per customer, which can hold multiple CAMPAINs. I´ve spend 500 hours so far since JAN-06 to solve this and the PEOPLE and ORGANISATION part works now, but my problem is my multiple customers with multiple CAMPAINS. Of course it would be better to have just one record for one person serving all CAMPAINS that the person belongs to but I don´t know how. So far I´ve solved it by having one FM8-file per CAMPAIN but thats a very bad solution. Regards Anders Söderman
comment Posted November 21, 2006 Posted November 21, 2006 You need a third table to join people to campaigns. There are many threads discussing join tables, here's a couple I picked in a hurry: http://www.fmforums.com/forum/showtopic.php?tid/181066 http://www.fmforums.com/forum/showtopic.php?tid/174996 http://www.fmforums.com/forum/showtopic.php?tid/173701
Newbies init2wn Posted December 22, 2006 Newbies Posted December 22, 2006 Ok I am having a somewhat similar problem working with multiple files. Database(s) to database Update: Need – Based on matching fields between records in different files update specific fields with information. Maybe use file reference with CASE or IF Else functions??? Not sure of the set up and syntax? Example: (showing a main database that can be updated by multiple databases[up to 10]) UpdateDatabase(s) Main Database PlanView = PlanView (shared between multiple updating databases) CREST = CREST (shared between multiple updating databases) Application = Application (unique to the updating databases) Assumptions copy to Assumptions Solutions copy to Solutions Hours copy to Hours Rate copy to Rate Etc. Example 2: Database A (1 record) Planview – P1234 CREST – G7890 Application – Database A Assumptions – “This is a test assumption for Database A” Hours - 812 Etc. (many fields that are not needed in the Main Database) Database B (1 record) Planview – P1234 CREST – G7890 Application – Database B Assumptions – “This is a test assumption for Database B” Hours - 256 Etc. (many fields that are not needed in the Main Database) Main Database (2 records) Planview – P1234 CREST – G7890 Application – Database A Assumptions – “This is a test assumption for Database A” Hours 812 Planview – P1234 CREST – G7890 Application – Database B Assumptions – “This is a test assumption for Database B” Hours 256
Ender Posted December 22, 2006 Posted December 22, 2006 Sorry init, this is not at all clear. What are the tables involved and why does the data need to get updated (why is it not in the right place to begin with)?
Newbies init2wn Posted December 22, 2006 Newbies Posted December 22, 2006 The reason for separate databases is because each Application (Department) in my organization has their own way of coming up with project estimates (I wish they would all do the same thing it would make my life so much easier). As a result Database A might have 40 fields used to create project estimates (ex. meetings, analysis, logic development, etc. [these are all categories that get labor hours and result in a total labor effort]) And Database B might have 140 different fields to come up with an estimate for the same project. Also there is a need to only have a certain fields to report on when delivering an overall estimate to the project sponsor. The project sponsor does not care about what each field is they only need the totals and summaries. I hope I did not confuse you further.
Ender Posted December 22, 2006 Posted December 22, 2006 Sounds like a candidate for a redesign. A good developer should be able to come up with a single normalized structure that fits the needs of most or all of the departments. It just doesn't make sense in the long run to try to maintain separate systems that do similar things. Anyway, it sounds like you currently have one record per Project. These really need to be in the same table if you wish to do any combined reporting. As a temporary measure, you could import the relevant project totals into a common table and run the reports from there. I'd also suggest you use real world names for your files and tables. A and B don't really communicate what you're talking about.
Recommended Posts
This topic is 6640 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now