I have an estimating database and a projects database. I have created a series of scrips to import estimating line items and est optional line items into a project.

I hit trouble when trying to import est optional line items into a project. I realised i was getting error messages when the GTRR was not finding any related records (some estimates dont have options - just the base quote line items). So i added some error capture and IF statements. However im not sure if i have the scripts/steps set up correctly.

I tried to import an estimate with options into projects. It imported the optional line items from the first record of that table, instead of those from the related record.

Could this have something to do with the line in my script which says ' Go to Record/Request/Page [First]. I had hoped that it would go to the first record of the related line items, but instead it seems to be going to the first record in that table and importing line items from there.

PDF of the script in question is attached.

script_with_GTRR_error.pdf

The first part should a test for related records.

If ( is empty( related::key field)

Message "oops"

Exit script

Else

GTRR etc

The second GTRR should instead be go to layout.

Another style to check for related is:

gtrr

if (get (lasterror) = 0) //gtrr was successful

do stuff to child recs

else

Dialog

Exit Script

endif

I've just had the chance to read your script and thought my comments might help:

1. After your first gtrr, you have Get (foundcount) = 0. But if the gtrr failed (no children), then you are still in the first table with a found count!

So, structure this as I suggested above.

2. Looping. Now that you are in the next table:

Loop

Set field to $$var

go to next (exit after last)

End Loop

That's all you need for this section.

3. Now you're gtrr New Window and Importing. Looks OK. However, after you close the window, you are back where you were before the gtrr, "OptionalLI_ProjectLI." I can't tell from your TO naming whether the next gtrr is valid. Is there a relationship from OptionalLI_ProjectLI > ProjectLI_PROJECT?

I suggest reading up on some Relationship Graph methodology white papers.

Edited June 18, 201015 yr by Guest

Thanks so much for your advice.

So can i skip the following command entirely. ie once im in the related table, do i automatically go to the first record regardless?

Go to Record/Request/Page [First]

revised script attached.

AmendedScript.pdf

Re Relationships - Yes there is a relationship between these tables - they all share the same projectID.

I am wanting to move from the project line items (where the optional line items have just been imported into) back to the main project screen to begin the next step in my script - which involves changing the status of the project to active and printing out a project sheet.

Do you think this is a bit clunky?

Your advice is much appreciated.

1. First set field (outside loop) is not needed.

2. There is no window "Import Line Items". The GTRR step created a new window but did not name it.

What is the logic of what's being done here? You're reassigning line items to a different project? Because if you can GTRR to them, they are already associated with the existing project, right?

You don't need the first Set Field outside the loop (as Bruce noted). You don't need Go to Record First (but it's nice style).

Your last ElseIF should just be an Else.

I second Bruce, at this point we're helping you neaten up a script, but is it doing the right thing?-- from here we don't have enough info.

2. The Import Line Items window is created in a previous script. I want to close it or there will be multiple windows left open.

3. This particular script is one step in a series, in which an estimate which has been approved by a client, is then used as the basis for a project record.

The est line items are imported into the project LI. From there the project LI that have not been approved are deleted. The ProjectID field was added to the est and optional LI so that upon importation, the ProjectID would link the project LI to the parent record. Does this make sense?

Would there have been a better way of going about this?

Also i wanted to leave the Estimate data (est LI and optional LI) in tact.

A zip file attached contains the overview script, plus individual scripts.

NB. I am yet to apply your suggestions to other sections of the script - but hope that this might provide an overview of what i am trying to achieve.

SCRIPT_PDFs.zip