Just about any fan of RDBMS should cover their eyes.... But for my project the database access was simple and straightforward enough that I generate all of my SQL at runtime without any problems. I send a collection of objects that describe the columns (coupled with values if it's an insert or update)... and I have classes that build a System.Data.IDbCommand object with it. Right now, I'd have to edit those to support another database, but when that time comes I plan on extending the class hierarchy and factory, or building something a bit more flexible to put the commandtext together.
The catch is that it works for simple selects, joins, updates and inserts. If you're gonna be picky about what order your columns list in, or need to do something more advanced.. It's definitely not the solution. It certainly upset the tinkerers over here, but with the most low maintenence persistence layer at the company now.. nobody gets to make me change it ;) ~Phill -----Original Message----- From: Murphy, James [mailto:[EMAIL PROTECTED]] Sent: Tuesday, April 30, 2002 4:10 PM To: [EMAIL PROTECTED] Subject: Re: [DOTNET] How are you supporting multiple DB vendors? *Dood* This is great. I'd still love to find a natural way to resolve the SQL dialect problem. I'm favoring Dan's suggestion about storing all query strings in DBMS flavored XML files and loading them at runtime. I bet they could be structured neatly... Jim > -----Original Message----- > From: Justin Rudd [mailto:[EMAIL PROTECTED]] > Sent: Tuesday, April 30, 2002 7:05 PM > To: [EMAIL PROTECTED] > Subject: Re: [DOTNET] How are you supporting multiple DB vendors? > > > > How am I expected to use this thing ? > > Two ways. > > 1.)You use OleDb for all your access losing the speed that > you gain from the Sql managed provider. > > 2.)You can use my project :-) > http://abstractadonet.sourceforge.net/ > > I've wrapped almost everything so far. All the wrappers > throw a common exception (DataException for now). In > addition to that, I also have a Mock ADO.NET implementation > for unit testing purposes. > > Justin Rudd > http://www.pinetree-tech.com/ > http://radio.weblogs.com/0107260/ > > You can read messages from the DOTNET archive, unsubscribe > from DOTNET, or > subscribe to other DevelopMentor lists at http://discuss.develop.com. > You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com. You can read messages from the DOTNET archive, unsubscribe from DOTNET, or subscribe to other DevelopMentor lists at http://discuss.develop.com.
