Quoting Paul McNett <[EMAIL PROTECTED]>: > [EMAIL PROTECTED] wrote: > > While I understand that using the 'denormalised' approach would simplify > the > > coding of the reportwriter, how does the whole app cope with extremely > complex > > SQL? For example, one report that I'm running at the moment uses 'insert > > into.. select from...' and takes an entire page. > > Wait a 'sec. What are you doing that the report needs to *insert* data into a > table? If you need to insert data into a table either before or after a > report > runs, that is one thing - and a completely separate concept from the running > of > the report. > > Running a report is *reporting on* data, not modifying data. >
Sorry, I didn't make it clear. The report uses a temporary table to collate and order data (because MySQL doesn't have a sub-select clause). How would Dabo handle something like this? > Okay, so for the other 20 tables, you probably want one form to maintain > those > things (loadPorts, stockTypes, etc.). Most of the time, your users won't need > to > add new stockTypes, right, so these would be simple, rarely-used forms. For > the > two main tables, perhaps one form could be developed for that. Yes, that's exactly what I envisaged. Matthew. _______________________________________________ Post Messages to: [email protected] Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
