LOL....glad to know that you do have it figured out though!

Hey Les -



One of the things I've always liked about our profession is that it is sometimes just as educational to prove one's self wrong as to prove one's self right.







The pudding is in the proof !

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

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.

Correct.

Oh, and this implies the answer to another related question: No problem having a BO that is comprised exclusively of CFPs, correct?


________________
_____/ Regards,
____/ al

Wow... Pandora's box! But I think I'm getting what I need (essentially that it may be time to play with the DDT).



Thanks for the posts/ideas.


________________
_____/ Regards,
____/ al

It seems it would be convenient to write the sproc in the DDT while having the data structure right there. Structure and sproc that fills it would live in the same DDT package.



It is the extended property key I was concerned about. If I deploy sprocs from primary ddt then deploy sprocs from structure ddt ( different named sprocs ) will the primary ddt sprocs survive.



Of course the best way it to try it. My test project almost finished, I'll post results.



Thanks for your patience.

I am not sure why you would want to do that so I might be missing your logic here. But as for the results, not really. There is an extended property tied to each sproc. So when one PKG deploys on top of the other, the key of the previous will remove the sprocs of your primary PKG file.

I completely get that. My question is, do you see any problem with having a DDT project that is structure only, maintaining the sprocs for those structures in that same DDT and then only deploying the sprocs to a database which is otherwise being maintained - schema and sprocs - by the DDT that actually represents the real tables.



Can just the sprocs be deployed from the structure only DDT project without messing with the sprocs that have been deployed from the primary DDT project ?