 | |
Check for record locking in scripts
comp.databases.filemaker comp.databases.filemaker
 |
| | Thread Tools | Display Modes |
#1
 
| |||
| |||
|
Check for record locking in scripts -
03-03-2010
, 04:02 PM
#2
| |||
| |||
|
|
FMP 10: I have a found set of line items I want to invoice them. I go to the the invoice table, create a new invoice, grab the key, return to my found set of line items and use the recplace command to put the invoice key in the appropriate field. If one of the line item record is blocked by another user, the script can't put the invoice number in. This line item does not make it on to the invoice, but all the others do. What do you do to address this problem: loop through the line items first, open them and check for errors? But every record will get closed as soon as you move to the next record, so we're still at risk here? Loop through the records when putting the invoice key in? Write invoices at three in the morning only? |
the invoicing. Most systems create an order/invoice and then create the
line items as a child of that parent. But if your business rules are
different, okay. I can see this model if you create a bunch of orders
and then invoice them all at once.
When you may have problems with record locking, yes, you can test
during the write loop for the locked record error. You can then pop up
a message for the user saying "one or more records were not assigned to
this invoice, try again?" Keep doing it until you get success.
Or, what should probably happen is that you take your Order line items,
and simply duplicate them as Invoice Line items. Don't use the same
line items for the different purposes. You can do this with an import
into an Invoice Line Items table, from your found set. Even if a record
is locked, it can be imported into another table, you'll never have
that interference again.
Or loop through and push the data into the second line items table with
a script. That lets you filter the line items and do error checking as
they are processed. Even locked records can be read from for this
process.
By having separate line items tables, you can apply different
discounts in orders or invoices, or add additional line items to an
invoice (for service charges, etc) that weren't on orders. You can even
combine line items or summarize them for the convenience of the
customer. When you do the import you can connect the two line item
tables with the KeyOrderLineItem so that they will always be linked.
--
Lynn Allen
--
www.semiotics.com
Member FBA
FM 10 Certified Developer
#3
| |||
| |||
|
|
FMP 10: I have a found set of line items I want to invoice them. I go to the the invoice table, create a new invoice, grab the key, return to my found set of line items and use the recplace command to put the invoice key in the appropriate field. If one of the line item record is blocked by another user, the script can't put the invoice number in. This line item does not make it on to the invoice, but all the others do. What do you do to address this problem: loop through the line items first, open them and check for errors? But every record will get closed as soon as you move to the next record, so we're still at risk here? Loop through the records when putting the invoice key in? Write invoices at three in the morning only? -- http://clk.ch |
Sorry if I do misunderstand.
But you don't use a join-table? Or is your line-item table a join table?
--
Keep well / Hou je goed
Ursus
#4
| |||
| |||
|
|
FMP 10: Loop through the records when putting the invoice key in? Write invoices at three in the morning only? |
This is the simplest. Use a Loop[] and Set Field[] instead of a
Replace[]. Capture the IDs of any Line Items that give an error and
as Lynn says, offer the option to retry.
G
#5
| |||
| |||
|
|
FMP 10: I have a found set of line items I want to invoice them. I go to the the invoice table, create a new invoice, grab the key, return to my found set of line items and use the recplace command to put the invoice key in the appropriate field. If one of the line item record is blocked by another user, the script can't put the invoice number in. This line item does not make it on to the invoice, but all the others do. What do you do to address this problem: loop through the line items first, open them and check for errors? But every record will get closed as soon as you move to the next record, so we're still at risk here? Loop through the records when putting the invoice key in? Write invoices at three in the morning only? |
I test the records at the start of the script (attempt to open the
records and evaluate for error), ( a status evaluation is better; Get (
RecordOpenState )) then open the records (to the user).
My recent multi-user same records issues are in an emergency department
patient management system, so 'high' concurrent demands and edits on
same records. Refreshing a live view as changes are made by one user,
only works if the record is first 'opened' then
committed/flushed/refreshed' an the end of the script (or so it seems to
me).
Your structural approach aside, test, and test again. Work it up in a
test environment and monitor concurrent logins, this is the only way to
see what is going on. Probably less of an issue in your scenario, is
forcing an update of changes to other users screens, so that they see a
'live' view of the data.
The real nut to crack is the issue of what constituents 'in use'. If the
user has left the cursor in a field that your script needs to edit the
record the field belongs to, then it will be 'in use', and the script
will baulk. Educating users to click outside the field once they have
finished editing is simply not reliable. A means of forcing exit is
required, and different fields require different treatments.
Fields with DDL/VL and such can have script triggers attached to force a
commit (release)
Scripted entries only need the commit...
The real nut is the free text entry fields. A timer script evaluating
keystroke lag seems appropriate. ( a time out force exit field in practice)
Custom Feedback messages can help (please get out of the field...), but
they need to differentiate from the standard FM in use by another user...
#6
| |||
| |||
|
|
Don't use the same line items for the different purposes. |
avoid redundant data (second normal form and all that).
--
http://clk.ch
#7
| |||
| |||
|
|
But you don't use a join-table? Or is your line-item table a join table? |
order when created and a second foreign key for the invoice when billed,
so that both the order and the bill display the same line items.
Billing means giving invoice numbers to existing order line items. Line
items can be edited when the foreign key for the invoice is empty.
--
http://clk.ch
#8
| |||
| |||
|
|
I test the records at the start of the script (attempt to open the records and evaluate for error), ( a status evaluation is better; Get ( RecordOpenState )) then open the records (to the user). |
of open records in the found set do not report an open record if the
reord is open in a different window. I concluded it wouldn't tell me if
record is locked by a different user Haven't tested that, though.
--
http://clk.ch
#9
| |||
| |||
|
|
Lynn Allen <lynn (AT) NOT-semiotics (DOT) com> wrote: [invoicing order line items] Don't use the same line items for the different purposes. Are there other reasons for this than the record locking issue? I try to avoid redundant data (second normal form and all that). -- http://clk.ch |
solution, but thought of the following paths.
With a join table create a 'connecting' record each time is needed. As you
only create it just in time, record should not be locked by any other user.
If you worry about redundant data you could run a weekly/montly cleen-up
or you could use a inbetween table with only global representation of the
fields you finally need. Since globals are 'per user' storing them would be
no problem, then a script could run until all fields got transfered and
emptied. This ofcourse would leave you waiting until transferring is
finished.
Or as suggested, create a script that present you with an error and says you
have to try again. Here also data could be stored intermediate somewhere.
None of those seem very elegant, perhaps something better will come up.
--
Keep well / Hou je goed
Ursus
#10
| |||
| |||
|
|
105<cortical (AT) internode (DOT) on.net> wrote: I test the records at the start of the script (attempt to open the records and evaluate for error), ( a status evaluation is better; Get ( RecordOpenState )) then open the records (to the user). I found that Get (RecordOpenState ) and its counterpart for the number of open records in the found set do not report an open record if the reord is open in a different window. I concluded it wouldn't tell me if record is locked by a different user Haven't tested that, though. |
should not have written better; should have written may be
probably why I implemented an actual try to open the record
|
« Previous Thread
|
Next Thread »
| Thread Tools | |
| Display Modes | |
Linear Mode
| |
Powered by vBulletin Version 3.5.3
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.
Copyright ©2000 - 2012, Jelsoft Enterprises Ltd.