Can someone look over posting code for parent child posting

[jaryder]

I have written a very simple parent/child (Older/Line) posting routine for totaling the quantity and price of a line to the order. In my real application I will have much more complicated code that will not work in the standard field rule posting function. I am new to Alpha 5 and this is my first project. I have a very simple test form that when you add, change or delete lines the order totals are updated. There is some xbasic code in the form init that creates pointers to the two tables and the other code can be found in the field rule's record events for the line file.

For the real application I plan on pulling the main posting code out of the events and put it in a function. For now I am just trying to get the basics down and not miss anything. It is based off of Dr. Peter Wayne's "Program your own Posting Rules" but have made several changes.

Any input is welcome.

Thank you,

Jeff

[Tom Cone Jr]

Re: Can someone look over posting code for parent child posting

Jeff, I'm not sure what you want folks to review ? Your order total is off because it's summing the costs instead of the product of each line's quantity x cost. Often it's useful to include a field in the line table record to hold the line total. In AlphaSports this field is called "Extended" in the order_items table, for example. To get the order total you sum the "extended" field values from each line record.

[jaryder]

Re: Can someone look over posting code for parent child posting

Tom, Thank you for looking at the code. I guess my example was bad. All it does it add, update or delete line quantity to order quantity and line price to order price. That is working correct as far as the test goes. I have been programming for many years but since this is my first project in Alpha and a big project that could replace existing software at over 100 locations I want to make sure I was not creating problems. I can not use the built in Field Rule posting option that automatically adds, updates and deletes a value to another table because of all the complicated calculations involved. I looked over the article by Dr. Payne but made changes because several fields in the items table can be changed and they all affect how you post to the order totals. Thus I used table.records_to _vars() to save off the entire line record before updates occur to the record. I think my code as written works fine but I was hoping that someone with more experience could take a look at it if they had time and make sure I am not doing something that could get me in trouble.

[Tom Cone Jr]

Re: Can someone look over posting code for parent child posting

Jeff, if the number of line item records linked to any particular order is reasonable you probably would find it easier to sum all the items each time an item record is saved or changed. DBSUM() runs very fast. In the long run this may be much easier to maintain than your current approach which adjusts the previously saved total for the order by the amount (plus or minus) of the line item record just saved or deleted.

[jaryder]

Re: Can someone look over posting code for parent child posting

Thanks Tom but that would not work. First off some of our customers have 60,000 or more orders and Line items reaching a million. There could be a couple hundred line items on an order. Also there is over 100 lines of code in our current product just for posting a line item to the order and inventory tables. The sample database is just for getting the code right in the various record events for the line table.

I will keep you suggestion in mind for other areas though.

Thanks,

Jeff

[Tom Cone Jr]

Re: Can someone look over posting code for parent child posting

Jeff,

My comments and suggestions are attached. Your approach seems to be working fine. The areas which concern me (and for which I'd welcome additional comment or criticism from others) are these:

a) You DIM shared pointer variables in your form layout and then reference them in your record event scripts in field rules without DIMMING them shared again, there. This is working fine, but makes me nervous. I'm used to thinking of UNdimmed variables as being local.

b) Since the pointers to your tables are initialized in the context of your form layout I fear you've tied your scripts to that form unnecessarily. You can establish a pointer to the LINE table in the record event scripts themselves. You can open a new instance of the ORDER table to write changes to it.

c) Your custom post will occur whenever the user changes a line table record using your form, even if that change doesn't involve the fields you need to post.

d) You use <tbl>.record_to_vars() in order to assign field values to separate variables. I've verified that this works well with C, D, and N data types, but have no experience with using it with other data types.

-- tom

[jaryder]

Re: Can someone look over posting code for parent child posting

Tom,

Thank you very much for taking the time to look it over and offer your options. I will do some more looking over the programs and do some more testing and revise my posting code with some of your suggestions.

Jeff