Trouble with Get Function

[MinnesotaHam]

Not quite a newbie, but have more experience with Version 6 and earlier.

I'm able to use portals and relationships OK.

Somewhat confused on tables but think I'm OK on this.

I have trouble with Get function for calculation fields.

I can make broad ones work such as Get Filename, Get Application Version, etc.

Some that I can't make work are centered around fields, portals and repeating fields.

I suspect my problem is a gap in my basic knowledge of V7.

Below are results for my calculations. Hopefully you can spot a pattern and give me a clue.

The test file (parent) is simple. A single relationship, single table, single portal, single repeating field, and a single calculation field. Yes, I am setting the calculation results properly to text or number as required for the calculation.

GetActiveFieldname always returns blank results

GetActiveFieldContents always returns blank results

GetActiveRepetitionNumber always returns 0 (zero)

GetPortalRowNumber always returns 0 (zero)

Any clue what I'm doing wrong ?

[bruceR]

Most likely you don't have an active field.

But it would help if you provided more informatioin and and a copy of your file or simplified example of what you are trying to do. Why do you want to do anything with active field?

[MinnesotaHam]

I do have fields, populated with data.

And I do move the cursor around as well.

Still can't make it work. I know it's something basic....

The intent is to archive some records by moving from one related file to another related file. I was trying to do this without exporting and importing since I though it would be easier.

Regardless, I still need to know what I'm doing wrong with the Get commands.

The parent file is types of vacuum tubes. The child file is ownership listings of each type. Example, for type 6X5 tube I may own fifteen different boxed tubes. As I use one of the fifteen for a repair, I want to move it from ownership file to an archive file for a usage history.

I'm fairly comfortable with calculations and syntax, but the majority of my previous experience was with flat files (and Status fields) and I'm stymied by failure to get some of the Get commands to report as expected.

I'm been using simple example files to try and solve my problem to no avail. I could certainly send them on but might be better to send something my way instead ?

I've looked thru the templates and example files and help files provided with the application.

Edited March 31, 2010 by Guest

[bruceR]

No, it would be better for you to send your file.

You mention "moving the cursor around" but do not describe what that is intended to accomplish.

Nothing you describe so far indicates any place where get() functions would be relevant. An active field is the field that has the cursor in it at the exact moment the calculation is performed.

There is no need to have two files. And even if you continue with two files, a reference to the second file can be created in file 1 and everything you are trying to do can be accomplished in file 1.

Edited March 31, 2010 by Guest

[comment]

For one thing, a calculation field using a Get() function needs to be unstored. Even so, moving the cursor around is not likely to change anything - simply because the screen is not refreshed.

[MinnesotaHam]

I have them unstored but tried stored as well. I also choose results correctly as appropriate (text/number etc). I mention moving the cursor around to different fields and repeating row to guarantee that a one of them has focus and the calculation field will report something.

Example one, I have three fields. Text field named Type, repeating field named Brand, and calculation field defined as GetActiveFieldName. I have all threee fields on a single layout. I'm expecting the calc field to return the name of the field with focus, and to dynamically update if I move the cursor around.

Example two, same as above only the calc field is defined as GetActiveFieldContents. I expect the calc field to return the contents of the field with focus and dynamically update if I move the cursor around.

Is my use of the Get command in a calc field in this manner, faulty ?

I hesitate to "send" a file not knowing how many will receive it. I did this a loooong time ago in a reply on a mailing list and they were not happy ;)

[comment]

I'm expecting the calc field ... to dynamically update if I move the cursor around.

As I said, this won't happen because the screen is not refreshed.

[MinnesotaHam]

I understood but didn't believe....thus iterated some details.

I'm now doing what I should have done sooner: dig out the manual and peruse the help files more. It's apparent my design needs to change to better use the table concept.

But now it has me wanting to see examples of how folks would use these two Get commands in a functioning solution.

Thanks for your patience. It is appreciated.

[bruceR]

For the most part they wouldn't be using them.

I really suggest you post your file. There is still no apparent point to your use of the get functions. The issue here is for us to see what you're trying to do. It is more effective and more considerate of the value of other people's time if you provide your file.

[Søren Dyhr]

I understood but didn't believe....thus iterated some details.

Eventhough calc'fields are there to make use of, isn't the behaviour spreadsheet'ish - a metaphor you probably are leaning your self conceptually?

--sd

[comment]

how folks would use these two Get commands in a functioning solution.

For the most part, you'd use them in a script - where they would be evaluated at script run time, regardless of what shows on screen.

I too do not see the connection between these functions and your stated purpose:

The parent file is types of vacuum tubes. The child file is ownership listings of each type. Example, for type 6X5 tube I may own fifteen different boxed tubes. As I use one of the fifteen for a repair, I want to move it from ownership file to an archive file for a usage history.

Moving records is generally not a good solution. When you use a tube, you should record the fact - either in the tube's record, or in another table. The tubes that do NOT have a record of usage remain available.

[bruceR]

I hesitate to "send" a file not knowing how many will receive it. I did this a loooong time ago in a reply on a mailing list and they were not happy

It isn't send, but attach. This isn't a mailing list; it's a forum, and it is designed to have attachments. Especially in this kind of situation, it is far speedier and more useful and considerate of the value of other peoples time if you attach the file. Besiddes - you said you're using repeating fields - you'll be better off getting rid of them and using a related table so we've got to deal with that as well.

Edited April 1, 2010 by Guest

[MinnesotaHam]

Here are two attachments.

One is an archive of the files I'm using for my solution. You can ignore all scripts in the "...Listings" file. This file is a clone of the main file where all the scripts came from.

The other file is a test file where I could not make some specific Get calcs work.

Forgive my lack of courtesy by not attaching sooner. Was thinking I only needed help with specific calcs not guidance on overall design. I was wrong.

Dale Saukerson

Thanks.

TestGet.fp7.zip

VacuumTubeDatabase.zip

[bruceR]

The other file is a test file where I could not make some specific Get calcs work.

Thanks.

That's right. They won't. Dead end. They are used by script trigger scripts, etc. That file is pointless.

[bruceR]

As for the other files - what is the problem you're trying to solve? Describe an example. And why so many files? You can put all the tables in one file.

Edited April 2, 2010 by Guest

[MinnesotaHam]

In the Main file, Tube Name is the primary field. It is a group of different kinds of vacuum tubes. In the Listings file, it shows ownership of these kinds by Tube brand (and other details). As I use a tube one at a time for a repair, I've been reducing the Qty in the Listings to show I have one less available in my stock. What I wish to do is not just show a reduced Qty on hand, but to built a usage history as I reduce the on hand Qty. The usage history will show what radio they went in to, repair date, etc.

The goal is to show on hand by kind (Tube Name) and also separately show usage by kind (Tube Name). There are approximately 300 kinds (Tube Names) with varying ownership for each.

Prior to wanting a usage history, it was a single file with duplicate entries for kind (Tube Name). Tube name became a key field when I made the solution relational to achieve paragraph two. Some of the files are not necessary to the chief purpose of this database. Feature bloat. It's obvious now that I failed to understand the concept of Tables. I do now. I upgraded from 6 to 7 but didn't do much new design work till lately.

What is good method to achieve goal in paragraph two ?

Lookups ?

Portal with match field for On Hand and another portal with match field for Usage History ?

[Søren Dyhr]

The goal is to show on hand by kind (Tube Name) and also separately show usage by kind (Tube Name). There are approximately 300 kinds (Tube Names) with varying ownership for each.

This is often solved via a recursive table structure ... or the transaction model, depending on the scale which rely on scripting.

http://my.advisor.com/doc/17403

--sd

[comment]

These two contradict each other:

As I use one of the fifteen for a repair, I want to move it from ownership file to an archive file for a usage history.

As I use a tube one at a time for a repair, I've been reducing the Qty

You either have a record for each individual tube in stock, or a record for the type only, with a Quantity field. The solution is different for each case.

[bruceR]

What you seem to be missing is the standard stuff of any business database: orders and line items, and purchase orders and PO line items. For each repair their should be an order, most likely with customer name, radio, etc. And then all the items used in the repair; which would include the tubes. When you purchase tubes, they get added to inventory.

[bruceR]

Some mods, pull tester table into main and remove tester file. Add tabs to main layout.

Vacuum_Tube_Database.zip

Edited April 3, 2010 by Guest

[MinnesotaHam]

Epilogue.

After trial and error for days, I have working solution. Perhaps not as refined as expert coders, but it's reliable and useful. As suggested, I combined multiple files into one and use separate tables instead. The main table is a collection of types of tubes. The child table is ownership of individual tubes within each type. As I use an individual tube, I wanted to:

1-note where it went

2-remove from ownership

3-move it to archive, still linked to tube type.

4-simulataneously see ownership and archived tubes by tube type

I was not able to elegantly achieve this with separate portals on a single page. My fault not Filemaker. I chose to move records from one child file to another child file for purpose of archive, then delete the original record. A traditional invoice/customer/line item solution did not fit my purpose.

It was for this that I needed to understand Portal row status and Get commands. What tripped me up was not understanding that some calculation fields work only in conjunction with scripting.

Thanks to all for the replies.

[bruceR]

"It was for this that I needed to understand Portal row status and Get commands. What tripped me up was not understanding that some calculation fields work only in conjunction with scripting."

No.

None of those command have any relevance whatsoever to what you are trying to do.

Edited April 10, 2010 by Guest