I cant quite decide which category to post this in, but here goes:

I am optimizing an earlier solution for speed in some scripts, and wanted to see if anyone could point out potential problems with this scenario. I want to delete blank invoice items created as result of users clicking on last line of portal (there are several portals on the invoice screen that create different kinds of line items. works great, but results in many blank line items accidently created)

2 files: Invoices and LineItems

4 relevant fields in LineItems:

t_InvoiceID (unique ID from Invoices file- identical in all line items for invoice)

t_LineItemText (what the invoice will display for this line item)

g_InvoiceID

c_BlankInvoiceRelate: case(isempty(t_LineItemText), t_invoiceID)

script:

set g_InvoiceID to t_invoiceID

go to related records(show) g_InvoiceID::c_BlankInvoiceRelate

Delete all records

go to related records(show) g_InvoiceID::t_invoiceID

print

my concerns are:

1. after the delete all script step, there are no records in found set. this does not seem to effect the ability to go to related records based on global field, but wanted to know if there is anything to watch out for.

2. if 2 users are running this script at same time, could the second user accidently go to related records based on the first users t_invoiceID? I remember that global fields are problematic in this way when using to set serial numbers for multi users, but am not sure if the same problem applies here, and I dont have a multi-user setup at home to test it out.

Also, if anyone has a better idea, would love to hear it. The above solution seems to work great- simple and very very fast, but I am nervous about the multiuser issue.

Much obliged!

First, globals are unique to each user as are current records and current found set. There is no problem with globals or relationships based on globals interfering. There is a possibility that a record will be in use by another user and not be deleted. This may not be likely. I would probably test multi-user status on startup and only run this maintenance script when there is only one user. It isn't like allowing a few blank records to build up is a major concern for speed. In printing reports, blank records can be omitted.

-bd

Thanks!

That was the reassurance I needed. Concerning "There is a possibility that a record will be in use by another user and not be deleted. This may not be likely.": in this situation, that could not happen because of other conditions in place- but I see your point.

As far as omitting blank records for printing, I assume you mean scripting something to sort out the blanks? like from invoice file go to related records (show) t_invoiceID::c_NonBlankLineItem ( case(not isempty(t_LineItemText), t_InvoiceID)), or is there a preformatted "omit blank" feature for printing that I missed?

Anyway, thanks again for soothing my worries.