Jul 2, 2009 at 4:09 PM

Found this today and had a real good play around with it. It copes very well with complex querys on 2M+ entries. Im wanting to try and use this in some production code and i was wondering a few things...

What options do i have to avoid file corruptions when adding rows? Could I copy the database file, add the rows, check for consistency and then delete the old file?

Is there an easy way to check a database file for consistency? How prone to errors are the files?

I've been working with .NET for less than a year but I'd be happy to help out where i can. Ive been looking for a simple database for c# like this for weeks and this is perfect!

Jul 6, 2009 at 9:57 PM


As I see it the .DBF is tough though, it is a very simple format. All records have the same size so there is no risk of overwriting or various structural  inconsistencies you could find in more complex data structures.

One good common way to keep out of trouble would be to backup the entire database (all the .dbf files) on startup or exit of the application. The index can be recreated so there is no need to backup them.

Also Dbf.Net should also still save your data even when the program crashes 'gently' as it relies on garbage collection.

In that scenario this is your choice whether you prefer to revert to the last backup.

There are situations where your records were modified in memory and did not have the time to go to disk because the .net framework crashed violently.

In that scenario the .DBF backup seems the best way to recover cleanly.

The marking of the .DBF file as 'dirty' until it is cleanly closed must have been implemented by dBase programs. I would prefer to use precisely the same method with DbfDotNet if someone has some info about it, I would gladly implement that.





Jul 6, 2009 at 11:02 PM
Edited Jul 6, 2009 at 11:40 PM

I've been reading through the source code so I should have a better idea of whats going on soon.

When adding a row is the number of records the last thing that gets updated? If this is the case, then if the software falls over before updating the record count then we would only use this record. It would be overwritten on the next insert...

However, what happens if the program crashed after updating only 1, 2 or 3 bytes of the 4 byte record count? You'd have to be pretty unlucky to end up with this sort of curruption, but it could happen.

Could this be an issue with any other fields?

One other thing I noticed was that after adding 500k rows, the application took about 3 seconds to close. Does this mean all these records were still in memory and had to be saved? If caching was disabled for write operations, is performance significantly affected? Could you have caching for reads but not writes?

I would be happy to help with the project where I can.

On 500k rows, no indexes, the following takes 5 seconds:

IEnumerable<Individual> result = individuals.Where<Individual>(x => x.dob < DateTime.Now.AddYears(-30)
&& x.dob > DateTime.Now.AddYears(-10)

string number = result.Count<Individual>().ToString();

Jul 15, 2009 at 10:00 PM

When I trying to open a dbf file with 'T' column data type, I get an error. How can I resolve this issue.