Re: ODBC and stored procedures???

Getting your code to run the stored procedure is only part of the problem. This has already been addessed by a response and I will not tackle it further. Two other things you need to thnk about are: 1) Portability of stored procedure code 2) Why would anybody want to write a truly portable application? First, the stored procedure code. DB2/MVS, DB2 CS, Sybase and Oracle have different methods of writing stored procedures. In DB2 the only method supported is a 3GL that creates static SQL. If you have ever written a 'traditional' mainframe 3GL application that accesses DB2/MVS you should be able to write a stored procedure. Sybase and Oracle have their own proprietry language for writing a stored procedure. Sybase, if you use their open server software, also enable you to write a stored procedure in a 3GL that uses static SQL. I do not know if Oracle has a similar capability. Therefore, it is likely that your stored procedure code (which could/should form most of the DML you use) will not be portable. If you really want it to be portable you will need to use a 3GL (this includes C, C++ as well as COBOL, etc) and use the facilities in Sybase or Oracle that gives you static SQL with a 3GL procedure. However, why should anybody want to write a portable application? OK, if you are selling your app to a wide market, portability is important, but having a common code base is a problem. If your app is going to be in-house only, then try to kill off the idea that portable SQL apps are a 'good thing' and easy to do. All RDBMS's have their own strengths, weaknesses and extensions to the ANSI standard. Often a strength is combined with an extension to the standard. This means that totally portable code is likely to run sub-optimally on any RDBMS. When you look at things outside the DBMS, like backup and recovery then you are stuck with implementation dependant code anyway. Almost certainly you will need to optimise your app to the RDBMS you are using in order to meet service level agreements. This optimisation can affect table design as well as SQL code, and can be caused by DML or DDL extensions as well as recovery requirements. My advice is choose your target RDBMS and make your app fly on it. -- Regards E. Vassie Address : Bastenakenstraat 49 NL-1066JB Amsterdam Phone : 00 31 20 615 2963 E-Mail : E.Vassie@Bigfoot.Com