Gregory,

I still don't think the view would really help as even after I requery, someone else may change the figure.

I'll look at changing my SQL update to SEEK, etc.

Thanks.

>Frank,
>
>If you had a view, you wouldn't need a trigger and you can requery() for one part# (have a look at the doc)
>
>Yes, a trigger is the better solution in your case, and I would rather use use, seek, lock, replace, tableupdate(), unlock(), use in than the sql update
>
>__________________________________________
>>Hi Gregory,
>>
>>I do have insert, update and delete triggers to alter the quantity on hand.
>>
>>I'm not sure how the view would benefit me. Can you explain some more how you would use a view to get around the problem?
>>
>>My goal is to ensure that the quantity on hand always reflects the actual quantity on hand. I thought a trigger would be best. Using other techniques I envisaged two or more people entering a sale against the same item at the same time (almost). Without the trigger, I would have to lock the item record update the qtyonhand for the first user, then release it, then do the same for the second user. I thought the trigger would handle this for me.
>>
>>The problem I am havingwith tracing the error is that there does not seem to be any code running besides the SQL in the trigger when the error occurs.
>>
>>Thanks.
>>
>>>hi Frank,
>>>
>>>Just an idea to get rid of the trigger.
>>>
>>>If you were to create a view instead, would it be fast enough ?
>>>
>>>btw, An insert trigger is not enough in your case. You also need an update trigger (sales order line is modified) and a delete trigger (sales order line is deleted)
>>>
>>>re your error message, you have to trace it ;-)
>>>
>>>___________________________________________
>>>>Hi Gregory,
>>>>
>>>>I am following the thread. This is the first time I've done a trigger like this (normally I wouldn't maintain a "Quantity on hand" field, but calculate it as needed) and had assumed that the normal error handling and transaction handling in my application (I use VMP) would manage any problems.
>>>>
>>>>I will look at the default VFP triggers and see how they work.
>>>>
>>>>I am still confused by the error message though :(
>>>>
>>>>Frank
>>>>
>>>>>>>hi Nadya,
>>>>>>>
>>>>>>>Yes, the trigger could be written with the following in mind and not caring about the field rules
>>>>>>>
>>>>>>>(1) The updates could be in a transaction which rolls back if any error (code/1887, ...)
>>>>>>>(2) I would reopen the table and use seek and scan rest and update on a record by record basis, and roll back / exit if any single record update failed. This means that if it failed at eg record 6, that the first five updates would be undone by the rollback
>>>>>>>(3) any routine must return TRUE or FALSE up the tree
>>>>>>>(4) you need a specific error routine
>>>>>>>
>>>>>>>Anyway, writing a trigger takes (imo) a lot more than writing a few lines of code (take a look a the standard trigger code for starters). You need at least error and transaction management
>>>>>>>
>>>>>>>The trigger below does not do any of that.
>>>>>>>
>>>>>>>Personally I think one must first understand how the standard routines work.
>>>>>>>
>>>>>>>Then you can either replace all (insert/update/delete/error, ...) with your own, or write one or more specific using the standard that is already there
>>>>>>>
>>>>>>>Cheers,
>>>>>>>
>>>>>>>
>>>>>>>ps, to know what is happening behind the scenes, take a look at the standard routines (modi proc)
>>>>>>
>>>>>>Gregory,
>>>>>>
>>>>>>Thanks a lot, I'm going to study that. I hope you sent this message to Frank too, so he can re-think his code.
>>>>>
>>>>>You're welcome. I did not cc Frank since my guess is that he'll be following this thread anyway
>>>>>
>>>>>You can rewrite the trigger code in a week or so and replace the lot with compacter and more readable code. This has the advantage that you can hook in your own triggers pre and post 'normal referential integrity'