[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.
I'm happy to do all of the testing for you- on a live project. I'm also going to
write up a tutorial for using AppWizardX and adding all the little features
we've discussed- this will give me practice, and also let me consider how
everything will fit together.
Excellent. BTW, AppWizardX is only a temporary name. As soon as it does
everything that AppWizard does (1:M relationships) and Ed agrees, I'll ditch the
old AppWizard and move AppWizardX to take its place.
Yes. The two main tables join the other (20) tables, for values like loadPorts,
stockTypes etc.
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.
--
Paul McNett
http://paulmcnett.com
http://dabodev.com
_______________________________________________
Post Messages to: [email protected]
Subscription Maintenance: http://leafe.com/mailman/listinfo/dabo-users
