Tranferring Records

[maulanday]

Hello Everyone,

I have this database that tracks all our projects for one client. I have a field with a value list (on track, behind 1 week, behind 2 weeks, behind more than 2 weeks, ongoing, finished). Is there a way by a click of button, I can transfer all the information in all of the fields into another database, which will archive these finished projects. So basically when the project is finished, I want to click on this button and will transfer all it's fields into a database with the same exact fields. Is that possible?

Thanks!

Maria

[Søren Dyhr]

Yes you can, but how healthy is it if this export gets interrupted. You could use the valuelists choices as a relational key as well, making different subsets for different layouts, while restricting access to particular layouts.

In my humble opinion should data stay where it's put originally - while the slicing and dicing of your data into some sence of meaning should be the work of the database system - not by moving it around!

I'm talking about a relational approach to the selection, which you might not have ...but even if you structure are what's considered "flat" should you bend it around a selfjoin, so you can make the measures i suggests.

Each record should have an autoenter setting the field with the valuelist to "on track" by the time it gets created - while the value finished should be removed, and put in a buttons Set Field, next to the pop. Because it would seem counter intuitive to make the record vanish from a layout by accidentally choosing the wrong choice in the pop.

This measure ought have a dialog as well asking something in the vicinity of "since you've pressed the button ...are you shure? Yes/No." etc.

Tell me if you should need some template to investigate/study?

--sd

[maulanday]

Yes. Please. I do need an example to understand better. I've only used FileMaker since Oct. 2005, so I'm didn't know if there was a way.

Thanks!

[Søren Dyhr]

Although I havn't restrained myself from throwing in more specialized solutions to problems ....is here a suggestion to a structure!

There should be something to dissect, and ask further about!

--sd

Projects.zip

[maulanday]

Thank you for the example. I see how the finished projects get moved to a different table. That's what I also want to do. But I want to be able to exclude each finished projects from the layout that shows each projects' history.

Is that possible?

[Søren Dyhr]

I see how the finished projects get moved to a different table.

No! No! No! I have apparently done a terrible job explaining, when I said I never move real data and only fiddle with the keys?

Let take an example from real life, you send a letter to someone who have left the adress you send the letter to. Now the friendly postman luckily knows where the reciever have moved to, and provides the envolope with a new address. This is a metaphor on how databases ideally handles data, it won't break the envolope to view what's written inside, it's kept intact just handed further to a new address.

In the same way will you discover when you tear the template apart, that the data never leaves where it put originally it's just shown in different locations as a reference according to it's status, just like the letters never leaving the letters contents in the metaphor, it's just redirected as entity (a letter) to a new place to show up.

But I want to be able to exclude each finished projects from the layout that shows each projects' history.

Is that possible?

You mean a sort of audit trail showing when it changes status, so it's an ongoing generation of records instead. All these record should then be excluded from the layout at the same time, when the entire project is finished.

Please notice that I have given you a button in the layout, showing either all records or records belonging to a certain person. completion could very well be the sort of filtering instead.

I think you need to investigate all the templates you can lay your hands on, including multicriteria relations ...to grasp the reach of the approach. Put my template under scrutinization to see whats goin' on, and then by a bit of abstraction see what it could do for you task at hand.

You should drill yourself with the concepts of both Table and Table Occurences and especially the distinction.

It's obvious that I miss a part here and there in your question, just as you missed a few of my original points of reasoning. This is down to very little provisions to go on, because I havn't conducted the interviews with the users myself, however if it were to be delegated should a sort of manuscript or schedule be responsible for correct gathering of information.

You need to wrap these principles and methods 'round your head and understand - there is no point in plucking turnkey methods as a blackbox ...you can't learn this by heart - you need to understand.

--sd

[sbg2]

I have attached a very quick, unfinished, example that may shed some more light on this. Its a simple Client layout with three portals. All 3 portals show records from the same table... Projects. Notice that even though each portal show records from the projects tbale only certain records are displayed in each portal. Think of a Relationship as how you would find related records manually. for example.....

If you wanted to view all projects for one client, Joe Schmoe for example, how would you manually go and find those records? Simple, we know Joe Schmoe's key is his ID_Member, in this case 1. So if we go to the Project layout and do a find for ID_Member = 1 we get all of Joe Schmoes Projects. So to show all of Joe Schmoe's Projects in a portal we would need a relationship box where:

Client::ID_Member equals Project::ID_Member

If you look at the relationship window you will notice a Relationship Box named Project_ViewAll where Client::ID_Member equals Project::ID_Member, this is the relationship you would use for the portal to show all the projects in the client database.

If you wanted to view only finished projects for Joe Schmoe how would you define a new relationship? You want to find all records in Project where the ID_Member matches and where the Status field in project equals "Finished". Notice the global field (g_Finished) in the the Client table which is set to hold one value only, that being the text "Finished". So if you create a relationship where:

Client::ID_Member equals Project::ID_Member

AND

Client::g_Finished equals Client::Status

you can show only finished projects for Joe Schmoe when creating a portal using that relationship. Notice the Finished Project portal uses the Project_ViewFinished relationship. If you edit the relationship between Client and Project_ViewFinished you will notice the the criteria is just as I describe above.

Lastly the main portal is set to show only projects that are not finished. In other words you want a relationship where:

Client::ID_Member equals Project::ID_Member

AND

Client::g_Finished DOES NOT EQUAL Project::Status

Notice if you edit the relationship for Client to Project_ViewNotFinished this is how the relationship is defined.

On another note.... I noticed in one of your other posts that you seem to have similar tables with the same fields save for 1 field that is different. for example your FACTORY table and LODGE table have the same fields except Factory has a field named Factory and Lodge has a field named Lodge. IMO these tables should be combined into one table with two new fields..... Type (where you select Factory or Lodge) and another field called Name. If you want to view only Factory's simply do a find find for Type = Factory.

Client_Project.zip

[Kyrvel]

Thanks a lot. The relations work great. I ended up restructuring the whole database.