ADO.NET related question
-
Friends, i've found a question with few choices on a newsgrop. I dont know the answer of this question. Please tell me the answer of this question and also tell me the reason. You are writing an application that is initially designed to use an Oracle database. You know that there is a good chance that your company will be changing their corporate standard database platform to Microsoft SQL Server in the near future. You are concerned that your application needs to function with a minimum of changes if the database platform ever changes from Oracle to SQL Server. Given the scenario above, how do you declare your DataReader objects to minimize the impact of a change to the database platform in the future? 1) OracleDataReader myReader = myCommand.ExecuteReader(); 2) OleDbDataReader myReader = myCommand.ExecuteReader(); 3) SQLDataReader myReader = myCommand.ExecuteReader(); 4) OdbcDataReader myReader = myCommand.ExecuteReader(); 5) IDataReader myReader = myCommand.ExecuteReader();
Imtiaz
-
Friends, i've found a question with few choices on a newsgrop. I dont know the answer of this question. Please tell me the answer of this question and also tell me the reason. You are writing an application that is initially designed to use an Oracle database. You know that there is a good chance that your company will be changing their corporate standard database platform to Microsoft SQL Server in the near future. You are concerned that your application needs to function with a minimum of changes if the database platform ever changes from Oracle to SQL Server. Given the scenario above, how do you declare your DataReader objects to minimize the impact of a change to the database platform in the future? 1) OracleDataReader myReader = myCommand.ExecuteReader(); 2) OleDbDataReader myReader = myCommand.ExecuteReader(); 3) SQLDataReader myReader = myCommand.ExecuteReader(); 4) OdbcDataReader myReader = myCommand.ExecuteReader(); 5) IDataReader myReader = myCommand.ExecuteReader();
Imtiaz
#5 - It is the interface that all others DataReaders are required to implement. However, the question does not guide you in the correct direction. You should create a DAL (Data Abstraction Layer) that can be swapped out when you change database vendor. The DAL is your application's interface to the database and only the DAL needs to care what the back end database is. Using just the interfaces supplied in
System.Dataisn't going to do much for you because you still need to construct the Connection, Command and DataAdapter objects which are database specific.
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
-
Friends, i've found a question with few choices on a newsgrop. I dont know the answer of this question. Please tell me the answer of this question and also tell me the reason. You are writing an application that is initially designed to use an Oracle database. You know that there is a good chance that your company will be changing their corporate standard database platform to Microsoft SQL Server in the near future. You are concerned that your application needs to function with a minimum of changes if the database platform ever changes from Oracle to SQL Server. Given the scenario above, how do you declare your DataReader objects to minimize the impact of a change to the database platform in the future? 1) OracleDataReader myReader = myCommand.ExecuteReader(); 2) OleDbDataReader myReader = myCommand.ExecuteReader(); 3) SQLDataReader myReader = myCommand.ExecuteReader(); 4) OdbcDataReader myReader = myCommand.ExecuteReader(); 5) IDataReader myReader = myCommand.ExecuteReader();
Imtiaz
-
#5 - It is the interface that all others DataReaders are required to implement. However, the question does not guide you in the correct direction. You should create a DAL (Data Abstraction Layer) that can be swapped out when you change database vendor. The DAL is your application's interface to the database and only the DAL needs to care what the back end database is. Using just the interfaces supplied in
System.Dataisn't going to do much for you because you still need to construct the Connection, Command and DataAdapter objects which are database specific.
Upcoming Scottish Developers events: * UK Security Evangelists On Tour (2nd November, Edinburgh) * Developer Day Scotland: are you interested in speaking or attending? My: Website | Blog
You may create a simplified and database-agnostic solution using an object-relational mapping product like NJDX. Even developing a DAL layer can get quite complicated if you have to use SQL/ADO.NET. This report shows how NJDX OR-Mapper reduced the complexity and size (70%) of the DAL code for the famous .NET Pet Shop project.
-- Damodar Periwal Software Tree, Inc. Simplify Data Integration