Leland,

I'm gonna have to disagree with you on this point. I don't think that using SPT vs SPs enhances portability at all, in fact I think it's just the opposite. Your argument is that when using SPT, you don't have to know anything about the back-end ... it could be Oracle or DB2 or whatever ... however, my argument is that you *still* have to make changes to your app in order to make sure you're accessing the right table names and column names in the back-end database (different back-ends could possibly have different names for tables and columns) ... so there are still many changes you would need to make in the app in order to support different back-ends. In using the SP scenario, you could be sure to have the same SPs defined in all back-end databases (even if you have to write the SPs yourself) and the only thing that would have to change in your app would be the connection to the back-end. Period.


~~Bonnie



>Hi Alejandro,
>
>Another consideration about whether to use Stored Procedures (SP) or SQL Pass Through (SPT) is portability. If I choose to use SP extensively in an application, I am making a serious commitment to the back-end server. Using SPs involves embedding part of the application into the back-end database server; thus, the application become married to the back-end server. Once a large part of your application becomes embedded in the database itself, it become almost impossible to port the application to another back-end server. If I used SP extensively in a MSSQL back-end database server, I am marrying both MSSQL as well as the window OS platform.
>
>If an application uses SPTs within the Visual FoxPro language, the application can be adopted more easily to whatever back-end database server and OS platform the client already has installed. This would allow multiple version of an application that could work with other databases like Oracle, DB2, Sybase, Informix, etc. Also, I could have a VFP front-end client running on windows workstations like NT, 2000, XP and a Unix, Linux, or Windows OS platform providing the database services.
>
>Also, it seem much cleaner to have the application separate from the database services. This would allow the application to be completely encapsulated within a VFP project as opposed to partly in VFP and partly in MSSQL. The back-end server would need only respond to queries submitted from the front-end client which is what MSSQL was mainly developed to do.