I didn't know whether to post this in the Oracle forum, or SQL Server forum, and certainly didn't want to post it in both...so I'll ask it here.

We're building a .NET application that will have to support both Oracle and SQL Server. For reasons that are too painful to go into...I'm not allowed to use stored procs. [basically, a perceived portability issue]. We know that we'll have to manage two code bases in the middle-tier [to count for the differences in Oracle and SQL Server syntax].

I fought as hard as I could against this, but unfortunately many on the outside spooked our internal management against using stored procs. One of the points was this...'SAP has to manage multiple database back-ends, and they surely don't use stored procs'.

I find it hard to believe that someone would actually know one way or the other how SAP would be doing things internally, but figured I'd ask.

At this point, unless I'm able to somehow convince our management otherwise, I'm stuck with having to maintain two code sets in our data access component, as opposed to being able to used stored procs in the two backends. No matter how you slice it, it seems you'll be maintaining two sets of 'something', whether it be backend code or middle-tier code. Seems to me you'd want to do the former, for performance reasons.

Any thoughts?

Thanks,
Kevin