ADO.NET

Should I use native parameter markers when binding parameters in my ADO.NET code?

Using native database parameters markers in your code means that the code cannot be used against any other database. In order to make your code as portable as possible across multiple databases, you should use the standardized parameter markers. The Microsoft .NET API does not address parameter markers; however, all Connect for .NET, Connect for ADO.NET and SequeLink for .NET data providers support the parameter marker ? (question mark), that has been standardized in JDBC and ODBC. However, you might need to use native parameter markers, for example, you have written provider-specific SQL code that uses native parameter markers. By changing one connection string option, the Connect for ADO.NET supports reusing that SQL code.

How do I return an Oracle Ref Cursor with Connect for ADO.NET Oracle?

Ref Cursors are returned as standard result sets. You do not need to bind a parameter to hold the output value of a Ref Cursor.

Ref Cursors are, conceptually, just a result set. Just as Microsoft SQL Server, UDB DB2, and Sybase ASE return result sets from stored procedures, Ref Cursors give you the ability to return result sets from an Oracle stored procedure. Connect for .NET, Connect for ADO.NET and SequeLink for .NET treat all of these the same way-as (multiple) result sets. This means that you can code for result sets returning from stored procedures in Oracle the same way you code for them in SQL Server, Sybase, or DB2. You do not need to use different code logic just to handle Oracle.

Can I use your ADO.NET providers with the Visual Studio .NET wizards?

Starting with Visual Studio 2005, you can use the DataDirect ADO.NET 3.0 providers with the VS .NET wizards. They are used exactly the same way that the MS providers were used in earlier version of VS.

Can the Server Explorer tool use your ADO.NET providers?

Starting with Visual Studio 2005, you can use the DataDirect ADO.NET 3.0 providers with the VS Server Explorer. They are used exactly the same way that the MS providers were used in earlier versions of the Server Explorer.

Will your ADO.NET providers work with the Microsoft OLE DB and ODBC bridges within Visual Studio .NET?

We know you will get the most out of ADO.NET by using database-specific managed providers that can provide the most support for your database. Therefore, Progress DataDirect will not provide support for anyone using our ODBC drivers or ADO data providers (DataDirect Connect products and SequeLink) with the OLE DB and ODBC bridges.

Here are some compelling reasons why we think you will not want to use these bridges:

• The bridges must call unmanaged code (code outside of the .NET environment), eliminating many of the advantages of the .NET managed environment, namely granular security and enhanced performance. Why take the performance hit?
• If you use a bridge, your code will be written for this bridge and must later be rewritten to use a database-specific ADO.NET data provider when it becomes available. The reasons discussed earlier that explain why moving from ADO to ADO.NET is a major undertaking apply here also: object names, schema information, error handling, and parameters; you will have to rewrite these parts of your code when you change from a bridge to an ADO.NET data provider.

Progress DataDirect has managed data providers for Oracle, Sybase, DB2, and Microsoft SQL Server. The SequeLink for .NET Client offers a managed data provider solution for other major databases. You'll save valuable time and resources by coding to these data providers instead of to the bridges.