Solved

Prepared Statements V Stored Procedures with RDO

Posted on 1998-07-22
2
206 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
[X]
Welcome to Experts Exchange

Add your voice to the tech community where 5M+ people just like you are talking about what matters.

  • Help others & share knowledge
  • Earn cash & points
  • Learn & ask questions
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

PeopleSoft Has Never Been Easier

PeopleSoft Adoption Made Smooth & Simple!

On-The-Job Training Is made Intuitive & Easy With WalkMe's On-Screen Guidance Tool.  Claim Your Free WalkMe Account Now

Question has a verified solution.

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

Article by: Martin
Here are a few simple, working, games that you can use as-is or as the basis for your own games. Tic-Tac-Toe This is one of the simplest of all games.   The game allows for a choice of who goes first and keeps track of the number of wins for…
This article describes some techniques which will make your VBA or Visual Basic Classic code easier to understand and maintain, whether by you, your replacement, or another Experts-Exchange expert.
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…
This lesson covers basic error handling code in Microsoft Excel using VBA. This is the first lesson in a 3-part series that uses code to loop through an Excel spreadsheet in VBA and then fix errors, taking advantage of error handling code. This l…

726 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