Randy (and David),

There was a discussion some time ago on this issue in the list.  I haven't
kept a copy of all of the material, so please bear with me.

There's a danger in thinking that the two format sets are interchangeable:

  If one uses the .DBF file for write access by another program,
adding/changing records, MapInfo may lose its links to the remaining
portions of the dataset, the .map, .id and .ind.  I killed a lot of work by
doing this to myself without realising the limitations.

One would be better off to think that the .dat format is 'the' native format
and use the .dbf format solely for import, saving as a .dat when the import
is complete.

You can, of course, output this way too, but, if you fiddle the .dbf
externally, you'd better delete the .map, .id and .ind files before
importing again or MapInfo will assume (disastrously) that it's still got
the .dbf data that it had before.

Further thoughts?



Stuart Cox
Map Generalization Technician, not
Resources Inventory Branch
������������������������������������������������������
Phone: (250)387-5529
FAX: (250)356-9430
email [EMAIL PROTECTED]
Check out the RIB Website at:
http://www.for.gov.bc.ca/resinv/homepage.htm



-----Original Message-----
From: Majors, Randy [mailto:[EMAIL PROTECTED]]
Sent: Tuesday, November 09, 1999 8:17 AM
To: David Bruce; Perry, Mike; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: RE: MI Native vs. dbf


David -
I think Mike's question is not being understood - I think he is referring to
a .dbf file which is part of a MapInfo table (layer) structure, not a
standalone .dbf file.  

Background:
MapInfo supports two table (layer) formats which are fully read-writeable on
all operations, one MI native (.dat) and one dBase III+ (.dbf)  (accessible
through File, Save Copy As, Save as Type, dBase DBF (*.tab)).  This makes a
MapInfo's table's component files one of the following:

MI NATIVE:      MI DBF:
.tab            .tab    (describes structure of the table, e.g. fields, etc)
.dat    OR      .dbf    (stores the tabular data of the table)
.map            .map    (stores the graphic objects)
.id             .id     (cross reference linking the .dat/.dbf to the .map
file)
.ind            .ind    (if present, index file for fields indexed in
.dat/.dbf)

We have heard from MapInfo support (and others) that their .dat file is
basically a modified .dbf file, so the question is - "why did MapInfo Corp
modify the .dbf into a .dat - why not just use a universally recognized .dbf
file for the tabular data which makes up a table/layer?"  Said another way,
what does the .dat do that the .dbf can't?  
(I have heard possibilities of the "way" that the .dbf stores integers is
not as efficient as the .dat, but is that the only drawback - the advantages
of a .dbf file format that other software can read (e.g. VB grid controls
can read .dbf) would seam to outway this disadvantage...)

Thanks
Randy



                -----Original Message-----
                From:   David Bruce [mailto:[EMAIL PROTECTED]]
                Sent:   Tuesday, November 09, 1999 6:32 AM
                To:     Perry, Mike; [EMAIL PROTECTED]
                Subject:        Re: MI Native vs. dbf

                Mike,
                The linkage of database records to map objects is integral
to the GIS
                functions in MapInfo [or any other GIS software].  The way
in which
                MapInfo implements the linkage - enabling creation,
modifying, and
                deleting of object attributes, as well as maintaining
logical database
                links to graphic objects which can be created, modified, or
deleted as
                well - is a proprietary expansion of the published .dbf file
format.

                David Bruce
                Pflum, Klausmeier & Gehrum Consultants, Inc.
                [EMAIL PROTECTED]

                "Perry, Mike" wrote:
                > 
                > If a .DAT is just a slightly modified .DBF that happens to
be larger in file
                > size, why does MI use it?  What is different about the
native files that
                > makes them superior for MapInfo's use?
                >
----------------------------------------------------------------------
                > To unsubscribe from this list, send e-mail to
[EMAIL PROTECTED] and put
                > "unsubscribe MAPINFO-L" in the message body, or contact
[EMAIL PROTECTED]
        
----------------------------------------------------------------------
                To unsubscribe from this list, send e-mail to
[EMAIL PROTECTED] and put
                "unsubscribe MAPINFO-L" in the message body, or contact
[EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]

Reply via email to