Not 3rd party applications... if you can write in VB.Net you can write a 20
line program to modify the structure of a .DBF file using say XHarbour
(which is free) and it will compile into a 32-bit .EXE or borrow a copy (or
have somebody write it) using FoxPro which will also result in an .EXE.
Come to think of it in either case you could generate a .DLL file instead.
There is also a scripting language version of XHarbour (XBScript I believe
it is called) which conforms to the MS scripting language conventions which
would work as well.  That way you wouldn't even compile it, you can
view/edit the script with any text editor.  None of these solutions cost
money, just time.

Of course it would be cleaner to do it in .Net directly.  The _NullFlags
column is an indication that it isn't standard DBF format.  As I mentioned
.DBF files don't understand the concept of NULL, empty fields are always the
empty equivalent of their datatype, e.g. "", 0, False.  FoxPro introduced
all sorts of things to beef up the .DBF format I assume to confirm to SQL
and eventually .Net.  I don't know which .DBF viewer you dl'd but it is
quite possible it just doesn't checks the header for the presence of things
it requires and ignores things it doesn't.  In other words it won't display
the content of the _NullFlags column (if you display the structure) but it
doesn't care that it is present.  I have no idea what Excel does to
determine if the .DBF file is intact but it could do a little or a lot.

If I had your problem I would begin by trying to determine if the DBF driver
has some sort of version or compatibility flag which you could set.  If it
could produce a bare bones (dare I call it "standard") .DBF then you're home
free.  Second I'd opt for the idea of passing it through a process I wrote
in a dBASE-compatible language and as I mention you could produce a .DLL so
you could it call it directly from your .Net program.

Third I might opt to produce the .DBF file manually which you mentioned in
one of your earlier messages.  It isn't a binary format BTW.  It's a text
file with a special header at the top followed by a series of fixed length
records.  The structure is well documented and public knowledge.

Oh there is another easy solution.  Is the resulting .DBF file a constant
format, in other words do you export a .DBF with a common layout and then
add a particular extra column to it?  You can create an empty .DBF with the
structure you want (probably using the viewer you dl'd and if not then using
any number of free tools).  This empty .DBF would have the structure you
want to end up with including the extra column(s).  You export the one
without the column using Access and then open the template using .Net and
import the data from the Access .DBF.  When you append records this way;
fields that aren't present in the source are just left empty in the
destination.  At that point your data has the proper structure and of course
you can fill the new field under program control once the import is done.

I wouldn't be too hard on the .DBF format.  It isn't ideal but then it was
designed in the late 70's and nobody figured it would be opened using .Net
and Excel at that time :-)  There is no central authority to improve it so
everybody went their separate way but unfortunately they kept the same
".DBF" extension.  The dBASE index files and memo files have undergone
customization as well but in those cases the companies actually did change
the extension so there aren't quite so many problems.

Tom