>>Just occurred to me that back in FPD days we were doing something I've never seen demoed in any tool... because it's a tad complicated. And "why would anyone need that" is the question with a ready answer.
>>
>>Here's the scenario. Form for data entry of a document (or anything else, for that matter), and at some point you need to create a FK into a lookup table. The lookup table is either too long or too wide for a combo, so there's a search form which opens up (this is where practically every demo loses me, they never have anything but combo at this point). In that search form you find your lookup record, except you notice a glaring error (ommision or commision, irrelevant) or you simply don't find it. You open up the lookup editing form (or if you're Mike Yearwood, it's the same form - right, Mike? - so you do it on the spot in the search form). Save the changed record in the lookup, return the PK of the found or edited or added record to the caller form... and, sheesh, you now need to refresh the cursor, assuming it wasn't the same cursor as in the lookup search and/or edit form. So you refresh that and we live happily ever after.
>
>I usually use the invoices, customers as the scenario for this. Believe it or not, a recent contract involved exactly my design, but they did not get it. The savings and stability would have been significant.
>
>The invoice form starts an add in an invoice details cursor. The user cannot find the customer by customer code. So the customer data-entry/picklist form appears. The cursor for the list page is the same cursor for the customer lookup in the invoice form. The customer form adopted the data session of the invoice form. Each cursor is distinctly named and always serves a singular purpose. A list of customers is always a list of customers. The user adds the customer in a customer detail cursor. The newly added customer record is inserted into the list cursor and tableupdate is suppressed in the list.

So the customer table gets its tableupdate when the invoice is saved then right? Not when you've created the new customer from the customer screen? My concern would be what if two users are creating the same new customer at the same time? -- then you have a problem. The advantage is that you don't have to requerry the customer view after you've closed the customer form and gone back to the invoice screen so it's easier to write - but it seems like you're kinda taking a chance by doing it this way......assuming I understand all this correctly.

>Further, the detail page control on the customer are added only when needed.
>
>>
>>Except that
>>1) a friend of mine is trying to learn c# and can't find a single example of the described scenario (actually can't even find how to refresh one cursor in a dataset or whichever data plough he's using)(Yes, Bonnie, you know who). Is it possible that nobody out there didn't have the need for such a scenario (and the ready answer to that question is "because we're introducing the system to a new customer and they want to create documents right away and fill the lookups as needed, not spend a week doing that before creating any documents, so we have to have this add-lookup-records-on-the-fly feature") or
>>2) is it possible that it was done thousands of times but my friend has ten thumbs when googling the scenario
>>3) or is it a completely different world than what we have here so they all did it but nobody is publishing because they aren't paid for it?
>>
>>So just for internal reference (and an internal bet), did you do this? In Fox, that is. I'm not expecting that anyone did it in .net, that's where "things are done in a different way", as I was told.
>>
>>(on the question of how to do it in c#... I don't care, let him suffer, and I don't want to know)