Generic Data Access Component???

SRigney:

I believe that the DbType conforms to Sql, oledb and oracle types.
The following url details a table and shows you what Dbtypes to use depending on the provider that you are using:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconusingparameterswithdataadapters.asp

Although, in saying this....it seems to only cover basic types. Specific provider types such as Cursor from OracleClient provider are not detailed.
I have managed to modify the generic data access component to acommodate the new OracleClient provider. I have been successful in calling a PLSQL stored procedure that takes basic input parameter types and output a number of PLSQL binary tables i.e. a recordset. This has been done using the OracleClient provider via the generic component.

But rather than using PLSQL tables to return a recordset we can use a single cursor object as an output parameter within the stored procedure. Coding the stored procedure is far quicker and easier....All you do is open the defined cursor and assign it to the defined output cursor parameter. Done...


_TAD_:

You suggestion in changing the stored procedure is specific for SQL Server is it not? I know in SQL Server the only way of return a recordset of data is to do a select * from table/joined tables. But i dont believe you can do this in Oracle using a PLSQL stored proc. To get a recordset out of an Oracle stored proc, you need to use either:

1) PLSQL Binary tables as output parameters
2) A cursor object as output parameter      

These are the only possible options within Oracle as i understand it.
And as i describe above, using a single cursor output parameter is far quicker and easier to implement.....within the PLSQL stored proc, you open the defined cursor and simply assign it to the output cursor parameter and thats it done.

I understand that Oracle uses the standard types for input parameters, but as you state yourself, it has the ability to return a Cursor type.  Microsoft SQL cannot return a cursor type, thus if you modify your generic DAC to handle a type of Cursor and try connecting to MicrosoftSQL then it will not work.  

You probably need to modify
Public Function CreateDataParameter(parameterName As String, dataType As DbType) As IDbDataParameter

to use Oracle specific objects rather than the basic DbType.  

You are at the point that many people get to.  Do I write my code generic so it can be ported, or do I write me code specific so I can get things done the most efficiently.  Up until now you have been using generic, but if you want to deal with a Cursor, then you MUST write your code to be specific to Oracle.  Access and MSSQL cannot handle this type.  Look for the corresponding Oracle object that lists all types.  There's probably some kind of enumeration within the Oracle object that deals with all of the types including cursor.  Use it instead of DbType.

ack...

I'm afraid you are correct.  I was pretty sure I had returned a select statement from a stored procedure in Oracle (like I do with SQL server), but after looking in some old code I am returning a cursor object(Oracle 7.3.4 and VB 6).

SRigney:

Can i just confirm, if we modify the function
Public Function CreateDataParameter(parameterName As String, dataType As DbType) As IDbDataParameter

to make use of the OracleType rather than DbType then we will also be returning the OracleDbDataParameter instead of the IDbDataParameter.
And if this is the case, we wont be able to use any of the existing generic methods such as CreateCommand......as this returns an IDdCommand object.  The CreateParameter method of the IDbCommand object would expect an IDbDataParameter rather than the OracleDbDataParameter.

Therefore, none of the methods within the generic DAC would be of any use as these all return interface types. We would moreorless need to rewrite all of the generic methods to be specific to the OracleClient provider i.e. create connection, command, dataadaptor and parameter....
Is this what you are saying? So we cant do what i was hoping for, all within the same generic DAC. Its pretty poor if this is the case :(

I don't think so...

If you use your WinCV.exe and query that class you should be able to see whether the class interfaces IDBCommand or not.

OleDbCommand Interfaces IDBCommand.... there for a statement like:

IDBCommand iComm = New OleDbCommand(<params>);  

will be a valid command and will compile properly.

If you haven't used WinCV.exe before you can find it in your visual studio directory (it comes with the .Net framework).

here is where I found it on my computer:
C:\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\Bin\WinCV.exe


Open up this application and where it says <search string>  type in the name of the class.


This will list all dependecies methods, properties, interfaces, etc.

If TADs suggestion doesn't show that IDbDataParameter is supported by the Oracle object, then yes you'll have to have everything be Oracle specific and rewrite the entire class.  I know it stinks, but it is what I was saying all along.

No comment has been added lately, so it's time to clean up this TA.
I will leave the following recommendation for this question in the Cleanup topic area:

Split: SRigney {http:#9782288} & _TAD_ {http:#9783473}

Please leave any comments here within the next seven days.
PLEASE DO NOT ACCEPT THIS COMMENT AS AN ANSWER!

TheLearnedOne
EE Cleanup Volunteer