dbms_lock.sleep(15 * 60);

But first you’ll need to give your user EXECUTE permissions on the dbms_lock module:

C:\>sqlplus sys@clayoracle3 as sysdba
...
SQL> GRANT EXECUTE ON dbms_lock TO my_user;

Grant succeeded.

If you’re trying this out outside a sproc, put an exec on the beginning, thus:

exec dbms_lock.sleep(15 * 60);

Note: dbms_lock.sleep() is known to be unreliable past about a 10 minute nap.

WAITFOR DELAY '00:15'

When a sproc returns a result set, in Oracle it takes a little more work to view the contents of that result set. But it can be done.

Simple example

As an example, say you want to call the spir_get_fooids_by_bazidkey sproc which returns a result set of foo ids, and you want to see what foo ids it returned. Here’s how that would look:

Advanced example

If the cursor’s package type has more than one column in it, you can fetch the output cursor into multiple variables and include them in the output. Or better yet, fetch ‘em into a package-type variable so that you don’t have to declare 50 individual variables, like in the following example.

Here’s an example where the sproc returns five result sets, two of which are large. We fetch one row at a time into a package variable and then print out the columns we care about.

Acknowledgments
Thanks to Akadia.com (and StackOverflow.com for the pointer).

To enable debug output:
SET SERVEROUTPUT ON

To list data tablespaces:
SELECT DISTINCT TABLESPACE_NAME FROM ALL_TABLES;

To list index tablespaces:
SELECT DISTINCT TABLESPACE_NAME FROM ALL_INDEXES;


C:\p4\team\EIC\clay\irqm\products\eic\src\i3dbtranintxsearchprovider\CI3DBTranIntxSearchProvider.cpp(326) : error C3861: 'ExecTranExecuteSearch2': identifier not found, even with argument-dependent lookup
C:\p4\team\EIC\clay\irqm\products\eic\src\i3dbtranintxsearchprovider\CI3DBTranIntxSearchProvider.cpp(465) : error C2039: 'ExecTranExecuteSearch2' : is not a member of 'CI3DBTranIntxSearchProvider'
        c:\p4\team\EIC\clay\irqm\products\eic\src\i3dbtranintxsearchprovider\CI3DBTranIntxSearchProvider.h(34) : see declaration of 'CI3DBTranIntxSearchProvider'
C:\p4\team\EIC\clay\irqm\products\eic\src\i3dbtranintxsearchprovider\CI3DBTranIntxSearchProvider.cpp(484) : error C2365: 'ExecTranExecuteSearch2' : redefinition; previous definition was a 'formerly unknown identifier'
dmake.EXE:  Error code 130, while making 'UnitTestDebugU\CI3DBTranIntxSearchProvider.obj'
dmake.EXE:  Error code 255, while making 'UDT'

“previous definition was a ‘formerly unknown identifier’”, probably in shades and a trenchcoat. Funny!

The size of an identifier cannot exceed 30 characters.

–from Oracle’sPL/SQL User’s Guide and Reference: 10g Release 1 (10.1)

June 3, 2010

Gerald Weinberg
c/o Dorset House Publishing Co.
3143 Broadway, Suite 2B
New York, New York 10027 USA

Dear Mr. Weinberg,

As a computer programmer of thirteen years, I have read and benefited from your writing – specifically, Exploring Requirements and Are Your Lights On? Thank you for working to understand what’s wrong with how the people within software development organizations think and articulating what needs to change and how. Your work has made a difference to me.

I went to your website this morning and saw that you have had a battle with cancer. Recently you were declared cancer-free — praise God for that!

Mr. Weinberg, you have had a brush with death, and because I love you I need to warn you of the Day of Judgment that we all will face. On that day, what will you say to the King?

I do not know the state of your soul before God, but I implore you, please do not deny the existence of the King. God who made the heavens and the earth and gave you every breath you’ve ever taken rules in righteouness, and he will call you to account one day. All have sinned and fall short of the glory of God. Only those who repent and believe in Jesus Christ will be saved.

Oh Mr. Weinberg, repent and be saved!

Sincerely and with love,
Daniel S. Meyer

I don’t have a mailing address for Mr. Weinberg, and I don’t know if his publisher will forward it on to him. Even if they do, how likely is Mr. Weinberg to repent? Am I not a fool for doing such a thing — not to mention for advertising it here? Where is my respectability?

Brothers who are in Christ: souls are at stake. Fool or no, I care about Mr. Weinberg’s soul. On Judgment Day I want to be able to look in the eyes of all, knowing I was faithful to warn.  And may God grant repentance to those He has chosen!

But is our decisionmaking driven by cool reason?  Yes, we say — by cool reason.

What about when we communicate our evaluation of a Microsoft tool to co-workers?  Cool reason?

Not usually.

The fact is, many of the decisions we make as developers are made based on emotional arguments couched in technical terminology.  Reading a post by Jerry Weinberg several months back brought on an Aha! moment that changed my thinking about us developers.

From Mr. Weinberg’s post titled Reasons, then:

…
Recently, I found myself recalling that summer day, half-a-century ago, when a client asked me to find out why their Software Engineering Process Group was having so much trouble getting people to adopt new software tools. It couldn’t be the tools themselves, they reasoned, because quite a few people had adopted them and liked them. So, I set out to interview both adopters and rejecters, to discover the reasons some were using the tools and some were not. Here are some of the answers I obtained:

Darlene: I installed it because the boss told me to use it.

Porter: The boss told me to use it, so I didn’t use it.

Ursula: I installed it because the boss forced me to use it.

Marcy: The boss forced me to use it, so I installed it, but I don’t use it. He wouldn’t know the difference.

Quentin: I used it because it was like what I used before, so I knew I wouldn’t have any trouble adapting to it.

Chuck: Why should I use it? It’s nothing new; it’s just like what I used before.

Carl: Hey, I used it right away, because it was new and different.

Cynthia: I’m not going to use anything that’s new and different. Too many things aren’t tested, and something’s sure to go wrong.

Mary: Of course I used it. Everyone else was using it.

Roy: Everyone else was using it – what a bore! You won’t catch me following the crowd.

Frances: Why should I use it? Nobody else was.

Edgar: Hey, I got to be the first one to use it!

Mort: I couldn’t use it. It didn’t do all the things I needed.

Alan: The thing I liked best about this tool was that it didn’t try to be a Swiss army knife and do everything anyone could possibly want.

Gerri: It was the perfect tool, because it had every feature I could possibly want.

Chico: Every time I hit a key by accident, it would invoke some obscure feature that I didn’t want in there in the first place. Finally, I trashed the whole thing.

Orion: I’m so busy, I needed a new tool to save me some time.

Belle: I’m so busy, I don’t have time to install and learn a new tool.

May: I’m not that heavily loaded. Why would I need a time-saving tool?

Paul: Well, I wasn’t so busy with other things, so I had time to install and learn a new tool.

Earl: It was freeware, so it was a bargain.

Justine: It was shareware, so it couldn’t have been any good.

Jacob: This tool costs $3,000. It must be good, so I’m using it.

Neelie: I’m saving the company $3,000 by not using it.

Willis: I won’t use it because I don’t like the way Microsoft makes software.

Samuel: I knew it would be good because Microsoft makes it.

—–

Well, there were more, many more, but that’s enough of the infinite reasons to make my point. By this time, you may have noticed that I have arranged these reasons in pairs. Why? So you could see the pattern that I saw:

Every single reason to use the tool was matched by the same reason for not using it – and vice versa!

In other words, these reasons may look like logic, but they’re not logic – they’re just reasons. In logic, the reasoning comes first, then comes the decision. But in real life, it’s usually the other way around – first we make the decision, then we make up whatever reasons we need to “justify” the decision and make it look like logic…

Going back to the Microsoft example again, when the Microsoft tool blows up, do we have cursings at the ready?  If so, would we have had similar cursings at the ready if it had been our favorite open source tool that blew up?  If not, why not?  Are we of a mind to be understanding toward our open source tool and impatient with our Microsoft tool?  (The question has the same implications if we reverse the inclinations — positing a tendency for patience toward the Microsoft tool and impatience toward the open source tool.)

What I have described is not a logical argument about a tool.  It is an emotional argument about a company.  Perhaps there is an argument to be made against the company (“Where possible I  do not support Microsoft because of its history of corrupt business practices regarding smaller innovators in the market” would be an example of a moral argument.)  Cloaking such a moral argument as a technical argument against a particular tool, however, is not honest.  As developers, we don’t even realize we’re doing this, but we need to realize it.  It’s part of being a professional.

Read Weinberg’s whole article.

We can do things our family members and friends can’t do. We can take lifeless bits, wave our hands, and make the code live! We have logic. We have design and problem solving skills. We have honed our technical prowess.

All this is good — but there is a problem: We imagine that we live in a larger world than the non-technical people around us. Brothers, let us not be deceived: our world is a smaller world.

What do I mean?

Our technical expertise does not help us prolong the life of our sick child — we thank God for the doctors and pray for grace.

Our design skills do not give us boldness to warn those who do not love Jesus of the judgment they face if they do not repent.

Our logic does not teach us how to live with our wives as with a weaker vessel, leading with honor, gentleness, and strength.

Our ability to do what others can’t do does not confer on us a special ability to honor our father and our mother as we know we ought.

These are matters of eternal import where we are no better than anyone else — and often worse!

Brothers, in our daily work we’re living in a virtual machine.

Yes, let’s continue to work to solve problems, to help people with our software, to work as unto the Lord — but let’s never forget that the rules are simpler inside this machine. The hard problems are out there. We don’t know how to solve those problems. Sometimes we don’t even try to deal with those problems — we hide inside our virtual machine, where the universe is smaller and the rules are better defined.

It’s not wrong for us to do our technical work. But we should be the humble ones, not the proud ones. Brothers, let us remember this.

It’s at these times that I get the nagging feeling — the test was so time-intensive to create and run, why not take the step of automating it so we can run it in the future and catch regressions ‘most instantly?

I wanted an SQL script that I could run that would INSERT the test data as it currently existed on my test machine.  And I didn’t want to create those INSERT statements by hand.  Boy, did I not want to write them all by hand.

Solution

Microsoft SQL Server 2005 comes with something called Database Publishing Wizard (look under Program Files\Microsoft SQL Server\90\Tools\Publishing\1.2\ ).  With the following command:

sqlpubwiz script -d MyDatabase -dataonly c:\temp\MyDatabase.sql

…I was able to generate INSERT statements for all the data in my little test database to an .sql script file.  I then edited the file to remove things I didn’t need (and to avoid key collisions by substituting NEWID() calls for hardcoded uniqueidentifiers as necessary).

Finally, with all the data in place, I could add the following tests. (If anything goes wrong, an error message appears in the Messages window.)

DECLARE @tempTable TABLE(BlahId      uniqueidentifier,
                         BlahType        int,
                         BlahDateUTC DateTime,
                         BlahLength  int,
                         PhoneNumber      nvarchar(60),
                         RightsMask       int);

DECLARE	@return_value int;
INSERT INTO @tempTable
EXEC	@return_value = [dbo].[blah_get_blah_chunk]
		@i_sessionId = @sessionId,
		@i_chunkSize = 50;

IF @return_value <> 0 RAISERROR('Return value should be zero but was %d', 15, 1, @return_value);

DECLARE @expectedRecords int;
DECLARE @actualRecords int;
SET @expectedRecords = 5;
SET @actualRecords = (SELECT COUNT(*) FROM @tempTable);
IF @actualRecords <> @expectedRecords RAISERROR('Expected %d records in result set but found %d', 15, 1, @expectedRecords, @actualRecords);

DECLARE @actualDisplayName nvarchar(60);
DECLARE @expectedDisplayName nvarchar(60);
SET @expectedDisplayName = N'blah_user -';
SELECT @actualDisplayName = (SELECT LocalPartyName FROM @tempTable WHERE RecordingId = N'a0ca1a4f-0933-4565-b5da-d8fc3222a42a');
IF @actualDisplayName <> @expectedDisplayName RAISERROR('Expected display name to be "%s" but it was "%s"', 15, 1, @expectedDisplayName, @actualDisplayName);

GO

In the future we could have a script test runner that keeps track of the output and flags errors as part of the build… but one step at a time, right? This already takes test scenarios that took more than a day to set up and makes them runnable in a minute or two.

Database Publishing Wizard can also generate script to create the entire database schema, but it’s the data generation that will support my unit test needs.

Thanks, Microsoft!

Acknowledgement

Thanks to Pinalkumar Dave for his helpful write-up titled Generate Script with Data from Database – Database Publishing Wizard