There may be a bit of confusion. But let's just recap, if you decide to create a pseudo table to which a BO will be mapped in a live profile, you cannot prevent that table from being deployed. That was the point I was trying to make and all I was getting at in regards to the SPROCs.

But in the scenario I'm describing I would want to deploy all the sprocs - they would be the sprocs that represented all the structures in my structure only DDT project. Are you saying they would mess with existing sprocs or remove sprocs deployed by the main DDT project which is maintaining the apps real data ? Maybe I'm misunderstanding how it all works, but I thought I could deploy just the sprocs from a project and existing sprocs wouldn't be touched. No?

Charles, I believe the problem is that you cannot select which SP will be deployed at the DDT, it is all or nothing, hopefully that would change with the upcoming overhaul. Also I found easier to have the DDT project just dummy tables, I make use of the "Category" to group all the DDT projects for one SF project.

Edhy Rijo

Charles,



Correct. Generally when I create a "fake" table to which I am only going to map by BOs, I generally create another profile so it doesn't dirty the actual profile or database itself (as Greg mentioned). But this is a very useful way to create CFPs easily when it will be lining up with a SPROC.

Hey Greg -



At first I was thinking just what you posted. But then on further reflection, if you a DDT project just for structures that never actually deploy to the backend, why not maintain the corresponding sprocs ( which will return exactly what the "table" says they should have ) right in the same DDT project with the psuedo tables they represent. Then the only thing you deploy from that project is the sprocs.



Either way works, of course, I just felt drawn to having the DDT project self-contained in this way.

I think the key idea is that you need to create another DDT project just for the CFPs (?)(I assume the schema that will be returned by the sproc). In you regular DDT project, you'd define the sprocs (along with everything else that actually gets deployed to the server). At least that's how I read it. Cool idea too!

Thank you both for these posts - lightbulb just went off with a lot of possibilities. Since, if I'm not mistaken, you can deploy just the sprocs from the DDT you could actually maintain the sprocs that filled the pseudo tables right in the DDT project, no?

Better solution:



Create a Database Deployment Toolkit project that you never deploy and it will in effect create the CFPs for you, but it is far easier to maintain. This is what I do when I create a SPROC that is returning a result set that isn't defined by a table, view, etc. It works great and saves a lot of time!

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