Solved

Prepared Statements V Stored Procedures with RDO

Posted on 1998-07-22
2
204 Views
Last Modified: 2010-05-03
We are using RDO 2.0.
Does anyone have any information regarding the relative merits of using prepared statements or stored procedures.

Particularly any quantative performance figures would be good but I'm assuming that these would be implementation specific.

Are there any views for the kinds of transactions/implementation that suit either approach best?
0
Comment
Question by:slinky
2 Comments
 

Expert Comment

by:vinoopauls
ID: 1466398
stored procedures always
0
 

Accepted Solution

by:
zimmy earned 100 total points
ID: 1466399
I would've sworn that I answered this last Thursday. Guess it got lost in the bit bucket. Oh well . . .

As a general rule, stored procedures are better than prepared statements; but there are always exceptions and special cases.

Here are some of the main arguments, pro and con.

Stored procedures execute faster because they are precompiled and optimized, whereas prepared statements must go through the parse, compile and optimize steps every time. (You're right, though. The improvement is so implementation specific that no one even bothers to try and do a general analysis.)

Stored procedures are better because, as a general rule, you shouldn't expose your tables to ANYONE. You should build views and stored procs as needed. This keeps control of the database where it belongs, with the developer and dba.

Stored procedures are better because they embody business rules that belong in the database. If your database has a rule that (for example) allows an account to be overdrawn by no more than $5.00, and three years later you want to change that amount to be $20.00, you don't have to track down every piece of client-side software that's been written in the interim; you only have to change the stored procedure. Nor do you ever have to worry that someone might not have received the word.

HOWEVER!

Stored procedures don't work if your query wants to return a column set that's defined at run time. That is, the columns specified in a SELECT statement can't be dynamic. For that, you need prepared statements.

That's about it. Hope it helps. If you have more specific questions, I'd be glad to give them a shot.

Zimmy
0

Featured Post

Free Tool: Site Down Detector

Helpful to verify reports of your own downtime, or to double check a downed website you are trying to access.

One of a set of tools we are providing to everyone as a way of saying thank you for being a part of the community.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

Introduction While answering a recent question (http://www.experts-exchange.com/Q_27402310.html) in the VB classic zone, I wrote some VB code in the (Office) VBA environment, rather than fire up my older PC.  I didn't post completely correct code o…
Introduction While answering a recent question about filtering a custom class collection, I realized that this could be accomplished with very little code by using the ScriptControl (SC) library.  This article will introduce you to the SC library a…
As developers, we are not limited to the functions provided by the VBA language. In addition, we can call the functions that are part of the Windows operating system. These functions are part of the Windows API (Application Programming Interface). U…
Get people started with the utilization of class modules. Class modules can be a powerful tool in Microsoft Access. They allow you to create self-contained objects that encapsulate functionality. They can easily hide the complexity of a process from…

830 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question