It's possible, but instead of "how to I copy data from portal 1 to portal 2"? Think "how do I copy data from table 1 to table 2"? In other words, you are actually copying data from/to the tables on which the portals are based.
A script can do this, but the details depend on the tables and relationships that make up your database. I can see some of that info in your screen shot, but not enough to tell which 4 Table Occurrences are involved. (Two parent tables (layout) and two child tables (portal).
From where (table occurrence ) to where (table occurrence) do you want to copy this data?
My portal from where i want to copy data is i placed on 'Technical sheet 2'
'Measurement' is the records which i have created in my portal in 'Technical sheet 2' - guess this is kind of a line items
On 'Measurement Types Template' - is where I have another portal where i create 'templates' I can add over into my portal placed on 'Technical sheet2'
'Measurement template' is the table where all records shown in the portal on 'Measurement Types Template' is going.
So basically I create a template in 'Measurement Types Template'. So fx the basic measurement info for a sweater. Which i then can pull up in my portal i technical sheet and fill in the measurement information. So what i want is to copy the info in my portal on 'Technical sheet 2' to the same portal just in another record.
This is the script being used to pull over the template over from 'Measurement Types Template' to 'Technical sheet 2':
If [ IsEmpty (TECHNICAL SHEET 2::Meassurements_type) ] Beep
Show Custom Dialog [ Title: "No Garment Type"; Message: "Please Specify Garment Type"; Default Button: “OK”, Commit: “Yes” ]
Go to Field [ TECHNICAL SHEET 2::Meassurements_type ]
Halt Script End If
Set Variable [ $Type; Value:TECHNICAL SHEET 2::Meassurements_type ]
Set Variable [ $GarmentId; Value:TECHNICAL SHEET 2::xTechnical sheet_ID ] Freeze Window
Go to Layout [ “GRADE SPEC Measurement temp” (MeasurementsTemplate) ] Enter Find Mode [ ]
Set Field [ Measurements Types Template::type; $Type ]
Set Error Capture [ On ]
Perform Find [ ]
If [ Get(FoundCount) = 0 ]
Go to Layout [ original layout ]
Show Custom Dialog [ Title: "No Measurement Template Found"; Message: "No measurement template was found for this type of garment please make one in measurement menu¶"; Default Button: “OK”, Commit: “Yes” ]
Halt Script End If
Go to Record/Request/Page
[ First ] Loop
Set Variable [ $TempMeasurementId; Value:MeasurementsTemplate::id ]
Set Variable [ $Description; Value:MeasurementsTemplate::MeassurementDescription ] Go to Layout [ “GRADE SPEC Measurements” (Measurments) ]
#Search if this measurement already exists for this garment
Enter Find Mode [ ]
Set Field [ Measurments::XgarmentID_FK; $GarmentId ]
Set Field [ Measurments::ID; $TempMeasurementId ]
Perform Find [ ]
If [ Get (FoundCount) = 0 ]
Set Field [ Measurments::XgarmentID_FK; $GarmentId ]
Set Field [ Measurments::Description; $Description ]
Set Field [ Measurments::TemplateMeasurementId; $TempMeasurementId ]
Go to Layout [ “GRADE SPEC Measurement temp” (MeasurementsTemplate) ] Omit Record
Exit Loop If [ Get (FoundCount) = 0 ]
Go to Layout [ original layout ]
Go to Object [ Object Name: "Sizingtab" ]
So what i want is to copy the info in my portal on 'Technical sheet 2' to the same portal just in another record.
Then I don't see the relevance of the Template information in getting this to work. If you already have this info in a record in measurement, linked to a record in Technical sheet 2 and you want a different record in Technical Sheet 2 to show the same measurement, you just need to duplicate the record in Measurement and update the match field of the new record to link to the other record in Technical Sheet 2. Or you could link the same record in measurement to both records in Technical Sheet 2 via a join table...
This would not seem to have anything to do with your template data. Thus, a script to pull over data from template would not appear to be the script you need to use here. Instead, I need to know how you want to go about selecting, first the measurement record that you want to copy over and then the Technical Sheet 2 record to which you want to link it. There are multiple options for how you might make those two selections.
Or am I misunderstanding what you need to have happen here?
not exactly sure how to explain it.
I guess it's basically copying data from the portal in record 1 (the record 'Technical sheet 2') to the same portal in record 2...
Then this has nothing to do with your template measurements.
But you'll need to tell me how this is supposed to work for the user. How do you want to select the measurement to copy over? How do you want to select the technical data sheet 2 record to which you want to link this copied record?
And I also suggested that you could link the same measurement record to two or more different Technical data sheet 2 records. Might that work for you?
What does linking exactly mean..? that if i make changes to record 1, record 2 will also change.
The issue is this:
The records (garments: 'pants red', 'pants blue', 'pants green'). 'pants red', 'pants blue' & 'pants green' will all have their seperate record when it comes to production. All the pants are exactly the same except from the color. So when they all go production stage the factory will need all the different pant's measurements regardless if it's only the color that set them apart. So instead of typing all the 20 different measurements categories (fly, waist, hem etc) in again again over 5 different sizes. I just want to be able to do it once, and then copy these measurements to the the other pants.
Yes, and that might be a desirable or undesirable thing to have happen for your database.
Whether you duplicate the record or link the same record to multiple garments is not a decision that I can make for you. Both options are the "best option" in different circumstances.
But what is unclear to me is how to determine which records will all be for the same basic garment but with different colors. From a basic design approach, I'd look at setting up a single record in a single table for the basic garment and then use a related table to list all the possible variations such as different colors or materials.
Then, only a single set of measurements need be specified for the "basic garment" record. Specs that specify a specific set of options for that garment would then use the relationships in place to list the set of measurements linked to the basic garment spec.
I think I'll go for the copy the info from one record to another.
Right now i differentiate between the different records based on 3 different fields
1) a style number
2) a Name
So fx "TD001 Sweater/A" and "TD001 Sweater/B" would be the same sweater but in a different fabric/color.
Ideally I would like to be able to freely copy info from the measurement portal. fx. copy the measurements from "TD001 Sweater/A" into the portal for "TD001 Sweater/B" and also the option to copy into "TD002 Cardigan/A" if that makes sense..? A kind of copy/paste between portals...
But how will the user make that determination? What interaction with your database will make that selection?
As I was reading your post, it first looked like all records with the same style number (TD001) should have the same set of measurements, but they you describe copying to TD002???
Please understand that I fully get the 'copy between portals' bit. What I am asking is how do you want to do it on the computer screen?
Will you click a button in a portal on one record, find another record and click a button in it to "paste" the data from the first record's portal into the second or do you have some other interface design in mind?
I see... sorry.
I was thinking of maybe check boxes and a option to check all boxes, and then a copy function. Then go to the other record and have a paste function. I just have no idea if this kind of 'paste board solution' is possible..?
Otherwise i would think maybe having a dropdown list with the names of the garments with content in their portal and by clicking on them they will copy into the portal..?
Each of the options that you describe are possible and they are not mutually exclusive.
Here's the basic method to "copy" one measurements record from one parent record's portal to another.
Put a button in the portal row. Later, after it's working, we can make it look and act like a check box field.
It's script is a one line (for now) script that set's a global variable to the primary key of that portal record.
Put a "paste" button on the layout, NOT inside the portal. The script for this button:
a) uses set field to copy the layout table's primary key to a variable.
b) goes to a layout based on the portal's table
c) uses the value in the global variable to perform a find to find the measurement record.
d) uses duplicate record to make a new copy of the record.
e) uses set field to change the foreign key field in the newly duplicated record to the value of the layout (parent) table's ID that this script set to a variable and thus links the new copy to the selected parent record.
f) returns to original layout
Once you can get this to work for "copy/pasting" a single record, I can describe some simple changes that will allow you to select multiple portal records ( or click a button to select all shown in the portal) by building a return separated list of the primary key values in the global variable and then the "paste" script loops though that list to duplicate and link each listed record.
But I really think that you should make long term plans to set up a "master spec" that links to a single set of measurements for all color variations of that single basic garment as this would, once the changes to support it were made, be a much simpler way of handling these measurements and making sure that all garments that specify that same "master specification" use exactly the same measurements. With the current approach, you run a very real risk that a garment could be made to the wrong measurements simply because it did not get set up with the same data as the rest of the garments with the same basic design.
This database is kind of made up as I go along, not sure what you mean by 'linking to a master spec'..? do you think linking is a better way to go around keeping it a bit more straight forward..?
actually thinking about it, i can't come up with a any scenario where linking wouldn't work. So all records with same style number and style name would have same measurements
I'm suggesting a major redesign of your database to protect better against what seems to be a real risk of getting costly production errors due to incorrect/inconsistant specifications for different garments that are only different in color rather than size and design. And that design would largely eliminate the need to do any copy/pasting or linking of records in order to set up the lists of measurements.
Such a change can't happen instantly, you may need to make the needed changes gradually and carefully. Thus, you may need the current "copy/paste" method for immediate use while you work towards a design that largely eliminates the need for it.
What I am suggesting is something similar to this broad outline of tables and relationships:
One record in BasicGarments stores all data specific to that basic garments (a particular pair of pants, for example), The related records in SpecificGarments would document the different variations of that basic garment design. You might have one record in SpecificGarments for a Blue pair of pants and another for a red pair. Since each of these garments are made to the same pattern and have the same measurements, you link your set of measurements to the "general specification" in BasicGarments instead of linking different copies of the same measurements to SpecificGarments.
I used to manage a database of manufacturing specs for a company that made screw on caps for glass bottles. A single manufacturing line could be set up to produce one of several hundred different caps. But they all had the same physical dimensions and all had to fit glass bottles with the same design to the neck of the bottle. But each was a different color with different art printed onto the cap and there were several different liners that could be inserted into that cap. Other lines on the same floor produced caps of different dimensions to fit different bottles.
So we had one table of general specs where the physical dimensions and some mechanical drawings were specified as this info was the same for all caps manufactured on that specific line. A related table then had one record for each unique combination of color, artwork and liner--the actual products that we produced and sold to our customers.
This design was crucial to maintaining good Quality Assurance control of the process. If a change was needed to what was recorded for the physical dimensions of that line's cap, That change had to be specified for all caps produced on that line, but because that info was kept in that one general spec record, we only needed to change the data in that one record and the info was then part of the spec for all the different caps produced on that production line.