One other point should be made that I hadn't noticed in any of the
follow-ups - even though the formats are similar in Xbase format, the Native
DAT format is inherently faster (approx. 3-5X) for record processing - this
is something that should be considered if you are dealing with a large
number of records which you plan to process in either MapBasic or SQL.
Regards
R.H. Jannini IV
http://www.mapONE.com
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Cox, Stuart FOR:EX
> Sent: Tuesday, November 09, 1999 5:43 PM
> To: 'Majors, Randy'; 'MapInfo-L'
> Subject: RE: MI Native vs. dbf
>
>
> 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]
>
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
