So, if I want a BO that will be populated via a stored procedure, do I really need to create a view or table just so the BOM has something to map to? I can envision CFPs coming to the rescue, except that seems like a lot of work to do v. setting up a view.



No biggie... just wondering if there's an efficient way to avoid cluttering up the back end.



TIA

________________
_____/ Regards,
____/ al

I tested my idea of keeping the sprocs that would fill tableless BOs that only exist as DDT structures in a project created for that purpose. The idea was to keep the sprocs with the DDT project that contained the structures described in them, then just deploy the sprocs, not the structures to the table



BAD IDEA



While the DDT will let you deploy just sprocs and you can point it to a Database that is otherwise created and maintained by a primary DDT project, deploying those sprocs from the dummy DDT will, in fact, wipe out the sprocs maintained and deployed by the primary DDT project.



Sooo, Table structures only in dummy DDT project so the BO mapper has something to point to. That DDT project never gets deployed.



SProcs that will be used to fill the BOs mapped to the dummy DDT will live with all the other sprocs deployed from the primary DDT project. Since the DDT lets you have more than one project open and you can easily flip back and forth there is really no advantage to doing what I was trying to do, even it if worked.

Hi Charles,

   It's a wise man who admits his mistakes. I'd post mine here, but like Fermant's Last Theorem, which couldn't fit in the page margin, there's not enough room on the Internet for mine...

Les