>Listen, on the project I was describing, there were 2 different versions of the entire system for 2 different store locations, both slightly different, but for no real reason other than the guy didn't think about data-driven design. (He hard-coded sales-tax rates into the code, etc).

Blech!

>
>So even just modularizing a few parts of the system and getting to one common codebase made maintenance much *easier*. Getting down to 1 customer lookup routine, totally encapsulated, instead of 14 x 2 versions greatly simplified future maintenance and also future development. Multiply that by dozens of similar parts of system that were simplified, and that's what I meant by ease of maintenance.

Indeed. I try to drive everything that I can from tables. In this current system I have what I call the "Task Manager". Essentially each Task is owned by one of the current employees. As long as that Task is owned by them it is accumulating time, which we'll later use for statistical information on how long each task takes. Each Task is able to be assigned by/to anyone of 'n' Entities. An Entity is a combination of Employees, Departments and Service Group (Customer Service, Agent Service, Information Service, Administrative Services, etc). Sound familiar? *g* Groups of groups. Each Entity then has its own Security setting and then, since I also know each user's ID, I can override that for them individually. IOW, Drew has essentially already written a huge chunk of my application and I, for one will not complaina bit! *g*

Anyway, when a current Task Owner marks it "Completed" they must assign it to one of 'n' next steps. Since each Task is associated to any number of Entities I can close the loop programmatically as to whom to assign this Task to. The Task Manager Form simply has a Timer event that issues a REQUERY() every 5-10 minutes and repopulates the Task Grid. The cool part is that when the user double-clicks on one of the entries the entry knows what form/process to launch. This gives me an infinite number of opportunities and combinations of Tasks & Entities. Some Tasks persist, based on the current user, some 'float' and so forth.

>You're just getting to the good parts. I've read most chapters at least three times, since I did a lot of proofreading during the beta. The security system chapter toward the end is lengthy, but *very* interesting.

Oh goodie! *g*

>I agree. Even if you don't end up actually using much of the framework, you'll probably get your money's worth from the documentation and studying Drew's examples and code comments (Have you looked at any of the "ZReadme" methods yet?). Well worth the money, in my opinion.

No, not yet, other than to read them a bit. Today perhaps

Best,

DD