I forgot to add a quotation from MS SQL Server 2005 Beta 2 Books Online: SQL Native Client (OLEDB) is a low-level, COM API that is used for accessing data. I need to migrate my code to support Yukon. Ok, I have a million lines of code written for Oracle that relies on that very old paradigm. I think I am gonna write an article about it myself. I need something like ODBC's SQLDescribeParam() or OLEDB's ICommandWithParameters::GetParameterInfo() methods or extend SqlCommandBuilder.DeriveParameters to support any SQL statemment.The usual answer I get is a peptalk about how great the disconnect paradigm of ADO.NET is and how bad is my code that was written 6 or so years ago following the MS recommendations du jour at that. If SQL Native Client (OLEDB or ODBC) for Yukon is not native, then what is?WHAT IS THE NATIVE API THAT PROVIDES MOST FEATURES FOR YUKON?I repeat, there are key features missing in SqlClient that I need. If I chose to use ADO.NET/SqlClient, there will be a bridge form my unmanaged code to managed SqlClient. My application code is not managed and will stay that way. Now you use the DataSet and DataTable objects instead, they operate as in memory tables. The new sqlclient in ADO.NET is similar to the disconnected recordset in ADO, however it handles updates differently. The MSDN Data Access Homepage () has quite a few similar articles that might be very helpful.=Creating tomorrow's legacy systems today.One crisis at a time.Īleksey,You are operating in the old paradigm with cursors and positioned updates. I think it may answer many of your questions. It's actually one of the slowest ways to access SQL Server.I'd look through this article. NET client.OLEDB isn't the native SQL Server client. You might also look into some of the factory patterns that let you write generic code on top of either the OLEDB or the. Does anyone have a better idea which client to use?-Aleksey The recommendations I get from MS are confusing. NET, I also consider using SQL Native Client (OLEDB), which I think provides the features I need.
This would work fine, but apparently it is missing some key features like cursors, positioned update, and "describe parameters". The first choice is ADO.NET and SqlClient. I am trying to figure out what data access method to use.
I need to write a data acess layer to port exsiting code from another database to Yukon. We've got lots of great SQL ServerĮxperts to answer whatever question you can come up with.
0 kommentar(er)
