Select All Portal Rows

[tininho]

Alô, I'm trying to duplicate a record in a layout that has a portal. When I duplicate the record the rows in the portal aren´t duplicated. I can´t figure out how is it possible to copy all the rows in the portal.

[Vaughan]

Search the forums for "duplicate portal" or "duplicate related records" this question comes up HEAPS of times.

There also may be some information in the TechInfo library at the FileMaekr Web Site -- look under Support.

[tininho]

Thank you Vaughan

[Zero Tolerence]

I'm sorry, but can someone explain the reasoning behind duplicating related records? I just don't understand where that would be useful.

[tininho]

My point is: -I have a database to record contrats and they have equipments (the equipments are added in a portal). When a contract expire I will need to make a new one and my objective is to duplicate the contrat with the equipments.

[Søren Dyhr]

But it's just because it's a historic document it's a legitimate desire. Thats why on the other hand, we make almost proverbial noises, often isn't there a just course, because the postulated metaphors contradicts relational principles.

However does it seem like you're on sufficiently solid ground to use what I have exemplified in this thread:

http://fmforums.com/forum/showtopic.php?tid/158870/post/158884/#158884

...what it does, is that deal with the situation, where only parts of a previous contract needs to get duped.

--sd

[Zero Tolerence]

My point is: -I have a database to record contrats and they have equipments (the equipments are added in a portal). When a contract expire I will need to make a new one and my objective is to duplicate the contrat with the equipments.

But just duplicating the original record will do this, there is no reason do duplicate the related records, as the "Equipment" will still be related to the duplicated record.

I fail to see the usefulness of your equipment records if they have numerous duplicates.

[Søren Dyhr]

Correct if the customer not says "with my usual discount" ...this will prevent the lines from being partial common with other contracts.

Unless the price calc is based on a common discount (from the main-table) for all lines in the contract, then would indeed an unstored field in the portal do, allthough the evaluation of the contract sum is based on unstored, and by it will take some time to evaluate.

--sd

[tininho]

[color:gray]

But just duplicating the original record will do this, there is no reason do duplicate the related records, as the "Equipment" will still be related to the duplicated record.

I fail to see the usefulness of your equipment records if they have numerous duplicates.

First of all thank for all for helping me solving my problem.

In my case the contrat must have another ID and also the equipments because they have multiple types of Interventions wich are related to multiple dates.

Edited April 11, 2006 by Guest

[Søren Dyhr]

Well Zero tolerance migh have a point though, what He suggests is a join table free many2many structure, which then have all the unique keys listed in a pilcrowdelimited field in the main record.

The way to issue documents is then to make a summary report where the foreign ID's then are grouped by type, but it is sometimes imposible to maintain such strict allocation, say a peice of equipment is disfunctional, and has to be replaced to fullfill the contract ...often does such replacements happen in the warehouse beyond datadicipline!

With a jointable could each type be counted from the contract interface.

I would say a rentalshop isn't just a rental shop, sometimes is a contract containing 100's of items to keep track of. But if the number of items to rent is there some good very ideas to investigate in this template:

http://www.nightwing.com.au/FileMaker/demos7/BookingSystem.zip

--sd

[tininho]

A few months ago I asked help for duplicating a contrat and the equipments that belong to the contract and I resolved the situation with the help of Vaughan, Søren Dyhr and Zero Tolerence. Now the problem is, they want to duplicate the contract and the equiments when expired but also the interventions and the dates of the interventions. I cant figure out how, if there is anyone who could help me I appreciate a lot.

[Søren Dyhr]

Might it be so that you can post a clone of your stuff I can fill in a scripted algorithm? Since I apparently wrongly supposed the linked threads to this thread - provided a fair coverage of various method to nail this issue.

--sd

[tininho]

Thanks a lot Søren Dyhr for trying to help me. This was my first database so fill free to say what you think is wrong : Hope you understand my database because its in Portuguese.

Contracts.zip

[Søren Dyhr]

Could you provide me with a clone sans passwords please?? There seems to be dependencies to .dbf files as well??

--sd

[tininho]

I forgot to took the startup scripts and the passwords. Already made a few changes to English.

Contracts.zip

[Søren Dyhr]

So it seems to be the checkbox logic that bothers, I've made a template a few days ago for this thread, where I could use the duping part of it ... the what it seems to be you are after is the choise to use either all or just some of the portal rows which should be recycled in a new contract. As you see do I think it should be solved via an extra TO...

--sd

Renewal.zip

[tininho]

Thanks again Søren for wasting your time with me. I will check you example and I hope it will resolve my problem.

[Søren Dyhr]

Sorry, but do not humble you into this - we the repliers get's just as much as the questioner out of participation in debates. Real life examples and problems are much much more important than teory, when the object is to learn fetch the correct piece to use a chess metaphor.

"asked players of various strengths to reconstruct chess positions that had been artificially devised--that is, with the pieces placed randomly on the board--rather than reached as the result of master play. The correlation between game-playing strength and the accuracy of the players' recall was much weak-er with the random positions than with the authentic ones. "

Snipped from: http://www.sciam.com/print_version.cfm?articleID=00010347-101C-14C1-8F9E83414B7F4945

Similar have Mike Harris said something that really substantiate this scientificly made observation:

http://network.datatude.net/viewtopic.php?t=107

So, replying questions made in this and other forums - are NEVER a waste of time ...but instead an attempt to get inner images or memory objects ready as instant attacks made by really thoughly drilled chess players.

Since I know what works in FM and since I think there are better, FM-centric ways of looking at these things, I have just wanted RT to go away and leave us alone. So far, RT ( as offered ) has done great harm to FM practice and no good I can discern.

The obvious incompetence of much FM work does not mean that data modeling is the cure, although it might be, properly presented.

--sd