Solved

Prepared Statements V Stored Procedures with RDO

Posted on 1998-07-22
2
200 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

Enabling OSINT in Activity Based Intelligence

Activity based intelligence (ABI) requires access to all available sources of data. Recorded Future allows analysts to observe structured data on the open, deep, and dark web.

Join & Write a Comment

Suggested Solutions

When designing a form there are several BorderStyles to choose from, all of which can be classified as either 'Fixed' or 'Sizable' and I'd guess that 'Fixed Single' or one of the other fixed types is the most popular choice. I assume it's the most p…
If you need to start windows update installation remotely or as a scheduled task you will find this very helpful.
Get people started with the process of using Access VBA to control Outlook using automation, Microsoft Access can control other applications. An example is the ability to programmatically talk to Microsoft Outlook. Using automation, an Access applic…
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…

747 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

Need Help in Real-Time?

Connect with top rated Experts

8 Experts available now in Live!

Get 1:1 Help Now