I would like to see some examples of simple flat file databases and how they are accessed through a data layer. I've written to and read from a flat file before, but I have not ever created a data layer that accessed the data for an application using text files.
If possible, it would be nice to see a tutorial that had a data layer that utilized a simple, custom flat file database. An example that saves custom business objects in XML and then uploads them would be nice because XML is so popular and easy to work with.
I would also be grateful for any links to websites that discuss best practices regarding the design of flat file databases, etc.
My goal is to have a solution for storing simple data on a user's machine and have them not need any special software installed (like SQL Server, etc.) in order to fetch the data from where it is stored.
I know this is a very general question, but any advice that can point me in the right direction is welcome.
You may have got your definitions a bit mixed up, understandable due to the large number of similar technologies around today.
XML isn't a flat file format (or flat file database), but from reading your goal it sounds like what you really want is a self contained relational database rather than an actual flat file.
Like others, I can strongly recommend SQLite for this purpose. There are bindings for various platforms, .NET has System.Data.SQLite which, in one file, is both the database provider and engine.
The 2 big benefits of using SQLite are that the actual database is completely self contained in a single file controlled by your application, and that it supports standard SQL DDL and DML commands (ie SELECT, INSERT, UPDATE, DELETE, CREATE DATABASE/TABLE etc).
For a single user application SQLite is an excellent (one of the best) ways of storing both application data and settings. Of late there has been discsussion that it can even support smaller scale multi-user applications.
However Oracle, MySQL, SQL Server etc are still definitely preferred for multi-user applications (even small-scale applications) if you have the ability to access/utilise a database server.
Also, don't forget that choice of database is not mutually exclusive.
You may have a multi-user application with a rich client UI installed on many users computers. The central database here should really be a multi-user db such as MySQL. But within the rich client UI, SQLIte is ideal to store each users settings, or perhaps to provide off-line support when the database can't be reached.