Hi Jerry > The more you build into it the more overhead you create. Not all > businesses > would need the object you are talking about, as well as other objects you > may think of. The beauty of the current system is that you are not > encumbered by unnecessary overhead and how somebody else thinks a process > should work. It's bad enough you have to deal with that on PC apps. If you > have a need for this then build it, but don't encumber the rest of us with > something we may not need. > Jerry
I would see this as an enabler, an alternative method and not a forced encumberment. If you don't want to use it, I don't see that it would really impact on performance on current methods, if it is done right. The elements are already in place, it is a matter of making the ITYPE concept more interactive, efficient and effective with BASIC, uniObjects, SQL, xml. This might entail a new command such as READI which reads virtual fields (itypes) into the attributes automatically, or stores the calculation in a variable similar to an equate statement process. Some of this can be built over the top of the current process, but there are limitations and inefficiencies which would be overcome if built we build some of these processes into the base. At the moment I am just putting a thought out their to see how we can develop U2 further and make it more inviting to a new audience of users, of course without undermining the current base. Regards David Jordan ------- u2-users mailing list [email protected] To unsubscribe please visit http://listserver.u2ug.org/
