What makes a field "Active"? (Script related)

[mdavis6537]

Hi,

 

Simple question (I think) - what makes a field "Active"?

 

I am trying to write a script that goes through the fields for a table record, and then using Get(ActiveFieldName), pull the name of the field and put it in another table (among other things).

 

The problem I have is no matter what I have tried, the "Active" field is always the same! I have tried using Go to Field, I also am using Go to Next field - but at the end of the script, it has pulled the name from the same field over and over.

 

I wonder if the only way to actually make a field active is to actually be clicked on that field? Is there another way to access a field and get its information via script?

 

My script is attached if you would like to take a look at it. If you are wondering why I dont just use a portal, its because I only want to display fields that have a value, and many of my fields will be blank, if that makes sense.

 

I appreciate any answers or help!!

[Fitch]

I'd bet that your Perform Script("AddScopeLineRecord") is going to another layout or something, so that the next time around the loop you're back at the first field again.

[mdavis6537]

You are correct - it does. I didnt realize that re-started the loop if you leave the layout. I suppose there is now way to add a record to another table without leaving the current layout which is linked to another table?

[Wim Decorte]

For speed reasons and to avoid this issue you could collect all the info for the new records in one variable and have two loops:

- one to collect all the info in variable(s) -> does not leave the context of where you are collecting from

- one to switch context to where the records need to be created and loop through the data in the variables to create the records

[eos]

Adding to Wim's advice: instead of stepping "manually" through the fields on a layout, you can use either

 

the design function FieldNames ( fileName ; layoutName ), to get a list of field names on a specific layout, or

 

ExecuteSQL with ExecuteSQL ( “SELECT FieldName FROM FileMaker_Fields WHERE TableName=’myTableName’” ; “” ; “”  )

where you can constrain the result further by adding WHERE clauses

 

to get a list of field names to loop through, set variables with field names and values for non-empty fields, then switch context and process these lists to create your related records.

[LaRetta]

Hi MDavis,

 

Honestly, looping fields is a rare need.  

 

"I only want to display fields that have a value, and many of my fields will be blank,"

 

Fields?  Or records?  I suspect you are in trouble with your file because it is requiring far more work than normal.  It is during these early stages of design, particularly if someone is newer to FileMaker, where the major mistakes are made.  And once you get further into the project, it will be extremely difficult to change the base structure.  

 

You have a forum here full of developers who are willing to help you if you get stuck but we can't help if we are working blind.  Context is king in FM.

[comment]

I believe this is a rerun of:

http://fmforums.com/forum/topic/90256-something-similar-to-a-for-each-loop-for-fields-in-a-table/

 

 

@mdavis6537

Please keep it down to one thread per issue. You don't have to accept my advice given in the other thread - but there's no reason to make others go through the same thing once again from the beginning.

[mdavis6537]

Just wanted to pop in and say thanks for all the replies. There are some solid suggestions here.

 

@Wim @eos - Thank you both - I think I will try and use the execute SQL commands and see if I can pull a list of field names that do not have blank contents and try to make that work.

 

@LaRetta - Thank you for your response. Currently they are fields. The reason there is so many for one table is because its essentially a large form that is filled out by a user so it has to show all the fields up front on the layout and allow them to select the ones that apply.

 

@comment - Sorry - it was originally designed as a simple question related to what makes fields active but seems to have spiraled from there. I do appreciate all your help and replies as you have tried to help a newbie out

[comment]

If you are sorry, why do you lower my reputation?

 

[LaRetta]

Comment was correct in his response to you, since it is this forum's policy not to double post.  Negative points are reserved for rude, disrespectful  behaviours.  If someone responds, that is a help even if you may not like what they suggest.

 

Comment, of all people, does not deserve a negative rating.  Since now it can not be removed, I will offset it.  He should have received a positive rating for assistance to begin with.

[mdavis6537]

I definetely didnt downvote you - not sure who did. But I upvoted, hope that helps.

[LaRetta]

Hi MDavis,

 

If you are moving data from one table to another then they are related.  And if they are related, they should be connected in the graph so you can take full advantage of FM native indexing.  This means that you can collect ONLY the ID, go to the other table, set the ID into the foreign key field, commit the record and return.  The remaining data can either1) be displayed by cross-placing fields (no need for redundant data) or 2) set as auto-enter or lookup if you need to track the values at the time of the action (such as for shipping address back through time).

 

Currently they are fields. The reason there is so many for one table is because its essentially a large form that is filled out by a user so it has to show all the fields up front on the layout and allow them to select the ones that apply.

 

Really, related records should be created when a User 'selects' a form item.  Keep in mind that, between Comment and I alone, we have at least 30 year's experience in this business and we know the possibilities of displaying and reporting data.  So you may think you need a single flat-file style solution but that is not the case at all. The fact that you are copying data from one place to another is the result and it probably isn't necessary at all.

 

If you are wondering why I dont just use a portal, its because I only want to display fields that have a value, and many of my fields will be blank,

 

You indicate that, for many of the times, several of the fields are blank.  This is a good place to split your data into 1:1 relationship.  In this way, the main fields which effect everything will reside in the primary table and you place related fields, grouped like you want on your form, into a few other tables.  But again, we can't tell you how to split the data without seeing it.

 

I suggest that you return to your prior threads where Comment explained this all to you before you get further down the wrong track.  We'll help you with it if you wish.