For forms having order and detail sections, Rich Starkey & I use a two table form. The first table we call formTable and it contains one null row in one column. All the 'heading' and subtotal information is entered in variables. These can represent the information which is constant for each row in the region which is related to the second table.
The information in variables related to formTable include the invoice number, invoice date, customer name, subtotals of prices and so forth that pertain to the invoice as a whole. You can't pull a column out of the detail and show it as a 'heading.' Every field from the table the region is based on has to be in the region. We tried using variables in a region for invoice detail but it became messy. Using f7 and f8 eradicate previous rows. Extended quantities times prices were also difficult. Rather than operate on a 'live' table, we use a temporary table which only represents the detail for that one invoice. The region works perfectly. When it has all been entered, calculated and reviewed, the 'header' information is inserted into a salesOrder table with SalesOrderID as the primary key. This value is added as a foreign key to all rows in the 'temporary' detail table. We call name such tables with a prefix of tt to represent temporary table: ttSalesOrderDetail. The table is then inserted or appended to a SalesOrderDetail table. You can give yourself all the 'empty' rows you would like in your region for ttSalesOrderDetail. Start with 20 and you won't have to 'add' any rows. Simply discard all unused rows by inserting WHERE productIDNo is not null. If a partially entered salesOrder is cancelled, the variables and temporary table are easily discarded. This design enables the ease and flexibility of tables together with the variable forms. Shall we see you in Pittsburg in April? Sincerely, Randy Peterson Tom Grimshaw wrote: > Bernie, > > I have created one particular region that is for speed entry of > invoice detail lines. Most of the fields are variables (so that > the changes can be displayed instantly) and it is undesirable to > have the values from the prior row appear in the following row. > What I do is have a row entry eep that clears the variables. > > BE WARNED! This procedure makes it inadvisable to go back a row > in a region as if the user does then the row returned to has the > variables cleared. In my case that requires reentry of the > cleared data. ================================================ TO SEE MESSAGE POSTING GUIDELINES: Send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: INTRO rbase-l ================================================ TO UNSUBSCRIBE: send a plain text email to [EMAIL PROTECTED] In the message body, put just two words: UNSUBSCRIBE rbase-l ================================================ TO SEARCH ARCHIVES: http://www.mail-archive.com/rbase-l%40sonetmail.com/
