This data I import to a TO.
There you go again.
You import it into a TABLE.
Importing new data to the table of prospects is my first step. That makes it available to the user. The user needs the capability to view what's been imported to that table of prospects. He gets that from the portal. There he must select who actually gets entered (and imported) into the actual table of members with the data in the appropriate fields.
I'm all ears but I don't understand how this process can be complete with just an import to a table.
1 of 1 people found this helpful
Are you saying you want to do the script for each row of the portal? If so, what you'll need to do is track a counter for the row number, so you can return to it after each iteration. E.g.:
Set Variable[ $rows ; Count( related::members ) ]
Set Variable[ $i ; $i + 1 ]
Exit Loop If[ $i > $rows ]
Go to Portal Row[ $i ]
Perform Script[ your script ]
The point that he is making is that it's a TABLE not a TO. Using TO when it's actually a table confuses people.
But importing or looking up this data will work and eliminate any need for global fields or a looping script.
To create a new record with this data in it:
a) perform a script to find just this one record with this "preloaded" data
b) Us import records to import the data into the Members table.
You'll need to store this data in a table with the same fields as Members but a true, separate table in order for import to work.
You could also set up a self join relationship such that just creating a new record "looks up" this data an automatically puts it in all of these fields. This would eliminate any need for a script, but requires a relationship that matches to just this one record.
Importing new data to the table of prospects is my first step. That makes it available to the user. The user needs the capability to view what's been imported to that table of prospects. He gets that from the portal.
What are you talking about?
Your continuing refusal to provide meaningful detail, and to use correct terminology, make it SO difficult for anybody to help you.
You now have three VERY skilled and experienced people trying to listen and trying to help you and it's just impossible.
And having the original form data in its own table, prospects, is the way I set it up originally, so that makes sense to me. It also allows me to keep the records of prospects after they've been imported to the members table. Now I must work on getting into the script a field that can note that the record has been used and should not show up in searches of prospects for entering new members again. (I'll make them available elsewhere to the user but only when he specifies those are the ones he wants to view. Maybe even make them available for reuse, in case he screwed up the first time. Or maybe just avoid the "already used" field altogether, unless the number becomes overwhelming. )
Thank you Tom.
This is very useful info for me. I won't use it here, as philmodjunk has provided exactly what I needed to know for this situation.
I knew as I was writing and rewriting that script that there HAD to be better way. I considered it a worthwhile exercise; I'm THAT new to this. Your information on loops and variables is appreciated and I'm sure I'll use that soon enough.
Let me see if I finally got this.
If I see one table in my Relationships--call it Members--then I have one table and one TO. If I see Members and Members2, then I have two TOs but still only one Table?
1 of 1 people found this helpful
Yes. Assuming they both point to the same base table (members).
This is where context becomes important, especially when doing things like scripts, layouts, and portals, and relationships.
Although it's your system, it seems like it would help to give the Members2 TO a different name; depending on how you are really using it. Certainly it would help others as we try to understand what you are doing.
For instance if your Webform table has a separate connection to MEMBERS then you might call that one Webform_Members.