Oracle and Visual Basic using ADO - Sources: http://www.vb6.us/tutorials/oracle-and-visual-basic-using-ado

VB6 tutorial explains how you can access an Oracle database from within Visual Basic. It is a bit short as it was thrown together from a post on the vbforums.com page. However if you check out the Sample VB6 and Oracle Source Code that goes along with it. You should be able to easily understand what is going on. Read on and enjoy as you develop your Visual Basic Oracle application.

Oracle databases have been around for years, and although they are not as popular as their Microsoft counterpart, many business rely on Oracle backends for all their needs. Because of this, we must know how to interface with an Oracle database from within our VB6 application. This VB6 tutorial will walk us through exactly how to do this.

To access an Oracle database it is very similar to how you access any other database. We can simply use an ADO Connection object. We set the provider to be our Oracle provider and setup our connection string and password.

1. Set dbConn = New ADODB.Connection
2. With dbConn
3. .Provider = "OraOLEDB.Oracle"
4. .Properties("Data Source") = "DatabaseName"
5. .Properties("User Id") = "someuser"
6. .Properties("Password") = "somepassword"
7. .Open
8. End With

After we setup the connection all we do next is setup an ADO Command object that will be used with our oracle database. This is the same things we do for any Visual Basic database application.

1. Set Cmd = New ADODB.Command
2. Set Cmd.ActiveConnection = dbConn
3. With Cmd
4. .Parameters.Append .CreateParameter(, adVarChar, adParamOutput, 50)
5. .Parameters.Append .CreateParameter(, adNumeric, adParamOutput)
6. End With

Now is where things start being specific to our Oracle database. Getting a result set back from an Oracle SP is not as simple as it is in SQL Server. The results must come back to the calling program in something called a reference cursor (ref cursor). This will discuss what a ref cursor is and how to implement them and get data back.

Oracle creates an implicit cursor for every select query (I think that is the same for any database system). The cursor is simple the recordset results. If you are not going to use that result set for anything else (ie: to generate another query to execute) then you do not need to declare a cursor. But to get the result set out of Oracle you need something that is called a ref cursor. This ref cursor is more or less the same as and ADO recordset. You declare the ref cursor in code some where on the Oracle database, that ref cursor (sort of a structure in .Net) is then listed as an In and Out parameter of the SP.

You generate the select statement you want to run then open the ref cursor you created as follows:

1. Open cRefCur For
2. Select ....... (columns form whatever tables)
3. From (table names)
4. Where (conditions and Joins).

Standard SQL here with one big exception since if using Oracle 8i or earlier, Oracle at that release level did not support the Inner and Outer Join statements. You must use the Oracle version of them. Inners are just and equal sign as in Sales.ProductID = Prodcuts.ProductID. The Outer join is a lot messier, outer joins use the same equals sign and also a plus (+) sign on the deficient side of the equal sign.

This is the way to create the cursor:

First we create a package that will hold all the different return types:

1. CREATE OR REPLACE PACKAGE cv_types AS
2. 
   
3. TYPE WellData IS RECORD(
4. WellName Varchar2(50),
5. ResultsCount Number
6. );
7. TYPE CV_WEllData IS REF CURSOR RETURN WellData;
8. 
   
9. End;
10. /

Next we create a stored procedure that will use that ref cursor declared above:
(This procedure does not have any inputs, only output paramters).

1. Create Or Replace Procedure WellCounting (
2. pWellName OUT VARCHAR2,
3. pCount OUT NUMBER,
4. rsWellData IN OUT cv_types.CV_WEllData)
5. 
   
6. AS
7. 
   
8. BEGIN
9. Open rsWellData For
10. Select
11. Wells.WELLNAME,Count(RESULTS.WELLID)
12. Into
13. pWellName,
14. pCount
15. From
16. Wells, Results
17. Where
18. Wells.WellID = Results.WellID
19. group by
20. WEllName;
21. 
    
22. EXCEPTION
23. WHEN OTHERS THEN
24. ROLLBACK WORK;
25. RAISE;
26. 
    
27. End WellCounting;
28. /

We can then call the stored procedure from VB as shown in the included VB Projects.

An example of a stored procedure with input parameters is here:

1. Create Or Replace Procedure OneWellCount (
2. pWellID IN Number,
3. pWellName OUT VARCHAR2,
4. pCount OUT NUMBER,
5. rsWellData IN OUT cv_types.CV_WEllData
6. )
7. 
   
8. AS
9. BEGIN
10. Open rsWellData For
11. Select
12. Wells.WELLNAME,Count(RESULTS.WELLID)
13. Into
14. pWellName,
15. pCount
16. From
17. Wells, Results
18. Where
19. Wells.WellID = pWellID And
20. Wells.WellID = Results.WellID
21. group by
22. WEllName;
23. EXCEPTION
24. WHEN OTHERS THEN
25. ROLLBACK WORK;
26. RAISE;
27. 
    
28. End OneWellCount;
29. /

We can also test these procedures (and ref cursors) from the SQL*Plus prompt by doing the following:

1. Enter the command SET SERVEROUTPUT ON;
2. Now we set up variables to hold data going into and out of the SP:
   Assuming we are using the first SP displayed, the we will need 3 variables:
   VARIABLE P1 VARCHAR2(50) This is because the field we are returning is 50 chars
   VARIABLE P2 Number This is a number coming back from the SP;
   VARIABLE P3 REFCURSOR This will hold the result set that is coming back
   
3. From the SQL prompt enter:
   EXECUTE WellCounting( :P1, :P2, :P3);
4. If the procedures completes successfully we can now display the output.
   The variable P1 and P2 will hold the last Well Name and number of results
   for that well name. The variable P3 will hold the complete recordset that
   is being returned. To display that result in SQL*Plus enter:
   Print P3