Not to be rude, but in addition to EZDBI there are also DBIx::Abstract, DBIx::DWIW, DBIx::Easy.
EZDBI: See my reply to the other post mentioning it.
DBIx::Abstract: aims at SQL abstraction, not just making things easier. I often find myself wanting to write queries myself.
DBIx::DWIW: New to me (again, a lowzy name, just like EZDBI), but is MySQL specific and seems not to be capable of returning rows one at a time.
DBIx::Easy: Another SQL abstractor.
So there isn't really competition, just different approaches to using DBI.
I think writing a DBI wrapper is becoming one of those tasks every Perl programmer undertakes, like writing a templating system :-)
That's why you see a lot of CGI scripts with sub query { ... } and sub dbopen { ... } in them. This just proves that DBI itself isn't easy enough.
I've written multiple DBI wrappers myself, and until recently, I created a new one for every project. I thought about how I would really like it, and how error handling in between prepare, execute and fetch* could be done, so that you can safely stack method calls and discover it went wrong later. The result is presented to you in this thread.
U28geW91IGNhbiBhbGwgcm90MTMgY
W5kIHBhY2soKS4gQnV0IGRvIHlvdS
ByZWNvZ25pc2UgQmFzZTY0IHdoZW4
geW91IHNlZSBpdD8gIC0tIEp1ZXJk