Well if you're worried about the ease-of-use with SQl, but you like the other aspects, why not use Access? You can still query access using SQL, but it also provides the pretty GUI for updating tables and such manually.
2GB size limit per database. This might not actually be a con. That's a pretty big DB as it is.
Difficult to access from Unix-based web environments.
Lots of data on the web on how to set stuff up
Reporting made easy
Easy editing of data
Corey loves Microsoft
[ QUOTE ]
We're leaning towards using an SQL database. Less likely to screw up, but harder to update.
[/ QUOTE ]
Hum... If a group of folks allowed to edit the Excel spreadsheets are "screwing them up", changing the storage technolgy to SQL is going to help this situation how? Sounds more like you need a process change, or training, rather than a technology change.
HytrewQasdfg, (is that a family name?)
I read about "2 level" data driven testing where you have one master table that points to child table(s) which have the data, expected/actual results, etc. I'm thinking my framework I'm developing will end up like that and I'm using excel/cvs files. I think there would be advantages to using a DB such as referential integrity, better reporting/analysis (flexible), easier to save and then query results, etc. And you can always output a flat file from the tables. Heck, I think I talked myself into this. And really alot of the "tools" out there that are add-ons for automated testing basically use a DB for these reasons. So, what do you think?