Kevin, my 2c :

Personally, I wouldn't use SP's. It would be too much of a challenge to create something for, say, Oracle, that can't be achieved in SQL Server (or the other way around). Furthermore, once going the path of SP's, you would be doing everything in there, right ? I'd say it would be too much detached from the app, while in fact it is about biz-rules. Think of the queries too. Lastly, I wouldn't go for "performance" reasons.

SAP, being a legacy package, obviously has to be able to deal with any DBMS. And, it will be installed on top of any data (in the database) already present within the organization. So I guess it is not so much of knowing SAP does this, but merely expect it from logic. See it like this : any package supplier giving himself the best chances in the market, won't prescribe the DBMS to use. So SAP won't.

I know, this isn't exactly what you wanted to hear. But there is always the possibility to use the common (SQL) standard, and use the common denominator of the commands only. It would leave you with one set of code only.
Anyway, that is how I would do it, and I did not do that yet. So don't ask me what technical problems you may run into. I am ahead of the same decisions, looking at my own product, being ERP just like SAP. So far it uses VFP DML only, and that has to change ...

HTH,
Peter


>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