"Forwarding" specific data

[AeroGuy]

Hmm...

So here's the problem:

I have two files, one called "LabInfo" and the other "RunningJob"...... In LabInfo, my laboratory writes, in one big textbox-like field called 'tests performed,' what tests they are running on a certain job. what i need is for the Lab to be able to identify which jobs are completed, and which jobs are not... this is easily done by putting radio-buttons off to the side, lined up with each line of my large text-field/box. so, every line of text in the 'tests performed' box has a corresponding radio-button off to the side where they can specify if the test is done or not.

what i want to do (and don't know how to do) is have all the tests that are completed, have that text in the big text-field/box get forwarded/transferred to my other file, RunningJob; from RunningJob file is where the secretary is going to know which tests to bill our customers for.

am i going about this whole thing wrong (the part about having the separate radio buttons off to the side)? how else would i be able to tell which tests are completed or still running? once these tests have been identified, how do i transfer the text over to the text-box of the other file?

Question1: what's the best way of identifying which tests are done or not?

Question2: once a test has been identified as 'completed', how do i write a script that'll forward this to the other file?

Thanks,

me

p.s. I tried this for the script but it doesn't work:

Set Field ["RunningJob::Tests", "RunningJob::Tests & tests performed"]

Go to Field ["RunningJob::Tests"]

Insert Calculated Result [select, "tests performed"]

.....where 'RunningJob::' is the relationship relating my two files, 'Tests' is the name of the field that i want to insert to in my RunningJob-file, and 'tests performed' is the name of the big field (text-box) from where i wanted to insert the text from.

would it be better if, instead of having the field as one big text-box, if i made it into a lot of smaller fields (one field for each test running/completed)? if i did that, i think my script will work... but that still doesn't solve the problem of identifying which ones are completed and automating the task of forwarding the info to the other file. peace.

[stanley]

AeroGuy:

I think the one big text field is your stumbling-block here. If you made a series of text fields, each with an associated radio button, you'd be much better off. What you'd end up with would be:

TestNameA (contains the text)

TestCompletionA (radio buttons, completed/running/not yet run)

Then the same for B, C, D, etc.

What you may also want to do is to put another field, hidden from the lab user, but visible to the secretary, which would be TestBillingStatusA (B, C, D, etc.) which would be Billed/Unbilled. If you create another field, hidden from all, which is a calculation field TestCalcA (B, C, D, etc.) of TestCompletionA & TestBillingStatusA, you can set up a relationship (for the secretary) which will only show those items which have, as TestCalc A "completed unbilled." How you show them to the secretary is up to you.

Once the secretary bills for the test, she clicks the TestBillingStatusA (as radio button) to "Billed," in which case that particular test will no longer show up in the abovementioned relationship.

Hope that helps

-Stanley

[stanley]

Just to be clearer, the fields you'd have in LabInfo.fp5 would be:

TestNameX (text field, formatted as text box, for entry of test name)

TestCompletionX (text field, formatted as radio buttons, for completion status)

TestBillingStatusX (text field; formatted as radio buttons on secretary's machine)

TestCalcX (text calculation comprising TestCompletionX & TestBillingStatusX)

-Stanley

[AeroGuy]

how exactly would i associate a radio-button with one of the 'tests performed' fields? the fact that each radio button is next to its respective 'tests performed' field allows only a user to know that they're related to one-another... but how would filemaker know? the layout on which i'm doing all this is in report-format... not a table/list... so i'm not sure how i'd do this.

thanks for all the advice you've given thus far.

~me

[Riley Waugh]

AeroGuy,

what you need to do is to have every test (line in the test field) be a separate record in the LabInfo file. Each record should have the following fields:

Running_Job_Number .... this is equal to your unique ID in the RunningJob fie

Test_text_data .... the notes on what has been done in this test

Performed .... your radio button boolean choice of done or not done

Tester .... who did this test

Date_OF_Test .... date field

Time_Of_Test .... time field

Now, you make a relationship bewteen the Running_Job_Number field in TestInfo and the like field in the RunningJob file which we will call JobID.

In the RunningJob file you can put a portal in your layout deifned by the JobID relationship and in that portal put the fields from the TestInfo file (JobID::Tester JobID::Test_Text_Data JobID::Performed)

Your portal will now show rows of test data for whichever Running Job your have selected in the RunningJob file. Each row will have the Performed field to give you the answer if done or not. You can then sort the portal by whatever helps.

if you want one big report of tests, covering multiple Jobs, you make this report in the TestInfo file using list view and summarys

[stanley]

AeroGuy:

Riley is correct - that is the more data-safe and logical way to deal with your situation. However, as far as what you've already got (and what I described to you) FileMaker wouldn't *know* about the connection between the radio button and the text field. You've got to make that connection yourself, in the form of the value of X in TestCalcX, TestNameX, TestCompletonX, etc.

Perhaps I wasn't clear about that naming convention. Where X appears above, you'd put in a numerical (or alphanumeric) variable. So, if you had space for three tests, you'd have three iterations of each of those fields, thus:

TestName1, TestCompletion1, TestBillingStatus1, TestCalc1

TestName2, TestCompletion2, TestBillingStatus2, TestCalc2

TestName3, TestCompletion3, TestBillingStatus3, TestCalc3

The problem with this is that you've got to have enough fields to accomodate the maximum number of tests you could possilby be using. If you've got 9 iterations and a job comes along with 10 tests, you're out of luck. If, instead, you use a system where each test is its own record & all tests are shown via a portal, you could have as many tests as memory can hold. This is essentially Riley's point.

-Stanley