Bruises on forehead remind me that "not as sexy" falls short of the mark ;-)
Nobody has mentioned embedded databases. To the extent that these might support ansi sql, your mileage may vary. SQLite: http://www.sqlite.org Firebird SQL http://firebird.sf.net/ Whether using jet or one the above, if you need to vary the sql syntax somewhat by db type http://sourceforge.net/projects/snapdal can help there allowing you to share sql when the syntax is the same, but vary it by provider type when it isn't. Then a factory returns IDbcommands configured with the correct types and sql. I'm surprised nobody has mentioned the OR/mapper route. The sql is (often) represented in an "abstract syntax" that is translated by the provider for the db. An example would be nhibernate that supports that sort of thing. Access, Firebird, SqlLite are all supported, but of course you have to drink of the OR/Mapper cool-aid http://wiki.nhibernate.org/display/NH/Supported+Databases?showComments=true#comments Finally, the dataset route isn't so bad. With 12 tables, defining child relations in a schema isn't going to take much time. You would still have to abstract your data access though with some sort of factory, perhaps in the way that snapdal does with named queries that pull the right instances as needed. --- "Pardee, Roy" <[EMAIL PROTECTED]> wrote: > I realize jet's not as sexy as a server db, but if the problem is > wanting to use SQL to manipulate data on the client-side, it seems like > jet is a perfect fit. I have a hard time imagining the perf would be so > much better w/mssql on this volume of data. (And wouldn't mssql stay in > memory regardless of whether anything was using it?) Philip - http://blogs.xcskiwinn.org/panmanphil "There's a difference between righteous anger and just being crabby" - Barbara =================================== This list is hosted by DevelopMentorĀ® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
