Hi,

>
>>I think it would be better to create them as views or no views at all, just specialized routines to build them as cursors anytime.
>
>I had though about this as a view, but what stopped me is that the SQL statement will be getting larger and larger (lots of unions? or is there a better way to combine from various tables?) as I keep adding Parent-Child table sets, of course there will be an upper limit to the no. of sets that will be in the final app. but as of right now I will be starting with the basic sets.


You missed I said "or no views at all, just specialized routines to build them as cursors anytime.". A view is a cursor definition anyway. Then you might instead roll your own cursor handling.


>
>>However since reporting/printing etc are generally done with some filters that needed time might be as short as a blink of eye. Pros of this approach is that you avoid the redundancy of data.
>
>I like this idea of avoiding redundant data. One more compelling reason I had fallen for Audit Table was that the user had requested automatic generation of narrations for printing in the ledger, for eg. for the sale account entry in uJournal.Narrations fields I would have generated and stored such a narration "Invoice no. 1, M/s. ABC Ltd., Rs.12345.67" for the party account entry in uJournal.Narrations I would have generated "Invoice no. 1" and so on for each and every account affected. This I do not see can be done in views nor SQL Pass-Thru?
>
>In fact, I have a Narrations Master with one record for each type of entry that will possibly be generated so the above 2 narrations will be stored in this master as follows: "'Invoice no. ' + ALLTRIM(STR(tSale.billno)) + ', M/s. ' + ALLTRIM(mAccounts.Name) ..." and "'Invoice no. ' + ALLTRIM(STR(tSale.billno))" I eval this at the time the audit table entry is generated and store it in the narrations field. Any way to duplicate such in either views or even SQL Pass Through?
>

Narrations (which I think of as print/display templates) stored in a table or anywhere, could be used with views/cursors. It looks like VFP9 report's listener. A different type of listener might render to different destination, style etc. With u* approach they have to be decided during data entry. With generate as needed approach, even users could define their own templates, no? For example I have a similar reporting where users are allowed to play with the template in frontpage (no wonder it's easier to find end user who can do simple FP processing then to find those that understand report designer:). Also u* approach is gluing presentation tier + data tier (sort of if not exactly). If you keep them separate it would be much more flexible.

PS: I said views for it's the popular one. My own preference is cursors that I can create, manipulate as I want.
Cetin