Free .Net data provider.

[Joel Silva]

Hi,

here is information about a free, simple and effective data provider for
Web and windows Forms.

..Net DatabaseHandler 1.1 was developed in C# and it may be used both
with .Net 1.1 and 2.0 applications.

It allows a developer to use the same API for accessing Sql Server 2000,
SQL Server 2005, MSDE, MS Access and MySQL.


How to use it:

1) Add a reference in your project to DatabaseHandler.dll


2) Add the following "using" statement in the class where you want to
use the component:
# using DatabaseHandler;


3) Instantiate the provider:

# SQL Server:
Provider provider = new Provider("MS SQLServer", your connection string");

# MS Access:
Provider provider = new Provider("MS Access", "your connection string");

# MySQL:
Provider provider = new Provider("MySQL", "your connection string");


4) The following methods are available for use:

# int provider.GetIntValue(command);
# string provider.GetStringValue(command);
# bool provider.ExecuteNonQuery(command);
# object provider.GetDataReader(command);
# DataSet provider.GetDataSet(command);


Example for the GetDataReader method:

# MS SQLServer
SqlDataReaderreader = (SqlDataReader)provider.GetDataReader(command);

# MS Access
OleDbDataReader reader = (OleDbDataReader)provider.GetDataReader(command);
# MySQL
MySQLDataReader reader = (MySQLDataReader)provider.GetDataReader(command);



More info and download at:

http://www.webdp.net/free-software/databasehandler.aspx


I hope it helps!
Joel

 

[Paul E Collins]

Provider provider = new Provider("MS SQLServer", [...]
Provider provider = new Provider("MS Access", [...]
Provider provider = new Provider("MySQL", [...]

Wouldn't an enum be more appropriate for these constructors?

Eq.

 

[Joel Silva]

Provider provider = new Provider("MS SQLServer", [...]
Provider provider = new Provider("MS Access", [...]
Provider provider = new Provider("MySQL", [...]

Wouldn't an enum be more appropriate for these constructors?

Eq.

Hello,

currently the Provider verifies if the first argument is valid by
comparing to a range of accepted values. If I add the possibility to use
this component with Oracle as well, I will have to change the range of
accepted values to include "Oracle".
I would have to change the enumeration definition as well so that the
Oracle provider would be accepted.

Of course it would be possible to use enum. It would be a matter of
handling internal code differently. I guess I simply did not thought
about that possibility.

Could you please tell me why you think enum would be more appropriate
here? Is there a "it MUST be an enum" type of reason?

This component helped me specially in applications running different
types of databases. The same API was enough for the most mundane
database operations.


Thanks a lot for the feedback. As I once wrote, any feedback is greatly
appreciated. And until now yours was the only one.

Joel
http://www.webdp.net/
http://www.webdp.net/free-software/databasehandler.aspx

 

[Paul E Collins]

Could you please tell me why you think enum would
be more appropriate here? Is there a "it MUST be an
enum" type of reason?

I was just thinking of compile-time type safety. If it's a string, you
can make a typing error like "SQL Srever" and won't start seeing
errors until the program is run; but if it's an enum, you're
restricted to a set of allowable values* and might get other benefits
like IntelliSense auto-completion.

Eq.

* Well, you can pass a non-existent member by casting, e.g.
(DatabaseType)93, but that's not easily done by accident.

 

[Marc Gravell]

Could you please tell me why you think enum would be more appropriate
here?

In support of Paul's comment: ease of coding. It avoids me, as an external
developer, from having to lookup the strings. I press ".", and it tells me
what is supported. If I insert a typo, it breaks at compile time (which is
good). Since you have to rebuild the base assembly anyways, it seems
reasonably convenient to add an enum entry.

Conversely, the data application block from the Jan 06 (latest?) enterprise
(patterns and practices) library uses string-based params; this is both to
support ConnectionString (config) usage, and to enable factory-based
extensibility (which I don't believe your code offers at the moment) w/o
rebuilding the base libraries (IIRC - might be wrong). This has support for
SQL-Server and Oracle out-of-the-box; I wonder if it might have been easier
(and more useful) to extend this to support your extras? (just s thought).

Marc

 

[Joel Silva]

I was just thinking of compile-time type safety. If it's a string, you
can make a typing error like "SQL Srever" and won't start seeing
errors until the program is run; but if it's an enum, you're
restricted to a set of allowable values* and might get other benefits
like IntelliSense auto-completion.

Eq.

* Well, you can pass a non-existent member by casting, e.g.
(DatabaseType)93, but that's not easily done by accident.

You are absolutely right. I did not consider the compile time type
safety. It does throw an exception if the database type is invalid but
just visible in run time.

Thanks once again.
Joel

 

[Joel Silva]

here?

In support of Paul's comment: ease of coding. It avoids me, as an external
developer, from having to lookup the strings. I press ".", and it tells me
what is supported. If I insert a typo, it breaks at compile time (which is
good). Since you have to rebuild the base assembly anyways, it seems
reasonably convenient to add an enum entry.

I understand the benefits. You and Paul are absolutely right.

Conversely, the data application block from the Jan 06 (latest?) enterprise
(patterns and practices) library uses string-based params; this is both to
support ConnectionString (config) usage, and to enable factory-based
extensibility (which I don't believe your code offers at the moment) w/o
rebuilding the base libraries (IIRC - might be wrong).

I am aware of the data application block and the use of strings. It,
more or less, gave me the idea that what I did was fine. And no, the
DatabaseHandler does not use the factory pattern.

This has support for
SQL-Server and Oracle out-of-the-box; I wonder if it might have been easier
(and more useful) to extend this to support your extras? (just s thought).

Marc

This would have been a good approach, but being relatively new to the
development of components, I wanted to do something from scratch and on
my own.

Thank you as well for your feedback!
Joel

 

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

I was just thinking of compile-time type safety. If it's a string, you can
make a typing error like "SQL Srever" and won't start seeing errors until
the program is run; but if it's an enum, you're restricted to a set of
allowable values* and might get other benefits like IntelliSense
auto-completion.

This is like a connection string, so it's fine to use a string, even if an
enum would look better.

There should be a reason why after so many years we still use connection
string (that we need to lookup somewhere) in the DB operations.