Fog Creek Software
Discussion Board




Welcome! and rules

Joel on Software

Stitch.Database - Easy .NET Database Access

Hello everyone,

I have just released a major build in an open source database wrapper I have created. I would really love it if people interested in .NET and database access could take a look at it, maybe read the Samples and Reference (both are pretty short and to the point), and give me some feedback (here or using the Feedback link).

The project is located at stitchdb.sourceforge.net. Samples can be found at stitchdb.sourceforge.net...ion/samples.html and the Class Reference is at stitchdb.sourceforge.net...n/refer­ ence.html.

Thanks to anyone who takes a gander at my project,

Paul Stovell

Nerdo
Tuesday, May 18, 2004

Oops, those links were

Site - http://stitchdb.sourceforge.net
Samples: http://stitchdb.sourceforge.net/latest/Documentation/samples.html
Class Reference: http://stitchdb.sourceforge.net/latest/Documentation/reference.html.

Nerdo
Tuesday, May 18, 2004

Paul,

Are the DBResult and DBRow objects inherited from ADO objects? That is, is DBResult derived from IDataReader, etc?

I ask because what if I had libraries that expected DataReaders, DataSets or DataRows. Would a user have to convert your objects into one of the ADO objects?

A few years, I built a similiar library to handle Oracle, SQL Server, OLEDB and Access because my client needed to communicate to a gazillion databases and I got tired of re-writing 80% of the same code over and over. The project turned into a hobby of sorts, so I'm always curious to see how other people tackle the same problems.

FWIW, I think your page on SF looks great, particularly compared to most SF projects. And I dig the logo!

Mark Hoffman
Wednesday, May 19, 2004

Thanks Mark!

Stitch.Database is just a single component I'll be using in a much larger software product I plan to develop in the coming months.

DBResult isn't derived from anything, and while it uses DataReaders, it's not inherited from them. What I would like to do, however, is handle the assignment operators so that it could convert to the different database formats - Eg, you could assign an SqlDataReader. When I first built the class, I didn't truly understand Interfaces, so it could probably do with a re-write!

DBRow is derived from NamedObjectCollectionBase (I think that's what it's called), and is simply an associative array of the cells in a result row. It can be iterated through using DBResult.FetchArray(), but I would love to later add functions to return all the rows for use in "foreach" blocks.

DBCell is my favourite, as it implicitly overloads the assignment operators to return the type it thinks you want. For example, you could do:

bool UserID = dbCell["ID"];
int UserID = dbCell["ID"];
string UserID = dbCell["ID"];
decimal UserID = dbCell["ID"];
Int64 UserID = dbCell["ID"];

And the right type of value will be returned - you don't usually need to use the Convert.ToX methods on it. But in the case where you need to specify what to be returned, you can always do:

bool UserID = dbCell["ID"].Boolean;
int UserID = dbCell["ID"].Int32;
string UserID = dbCell["ID"].String;
decimal UserID = dbCell["ID"].Decimal;
Int64 UserID = dbCell["ID"].Int64;

One thing I might do is if the casting ever fails, I'll catch the error and return "" or 0 or null, which will usually seem cleaner.

The component was just designed to make things easier for me. I use it with ASP.NET for a web site, and I plan to use it a lot more later, and things are usually added when I think of them.

Thanks for the interest! If you're you'd like to know more of the code, download the release from the downloads page, or email me (or use the feedback form) and I'll do what I can!

PS: I also plan to release another component, Stitch.BugReport, which is an unhandled exception reporter and will work with ASP.NET as well as win-forms. Hopefully I can do this before the end of the month!

Nerdo
Wednesday, May 19, 2004

*  Recent Topics

*  Fog Creek Home