If you want to use a dbf file and not lose the
geographical location of the record, after you have
geocoded the record, have Mapinfo save the lat and
longitude in a new field in the dbf file. Then you
can do what ever queries you want on the file in a
program like Access and then regeocode the results
using the lat and longitude (no misses that way). I
like using this approach for non-geographic queries on
data because I understand the querying better in
Access and Paradox better than I do Mapinfo SQL or
Select.
--- "Majors, Randy" <[EMAIL PROTECTED]> wrote:
> Stuart--
>
> Very good points - thanks for the clarification!
> Randy
>
> -----Original Message-----
> From: Cox, Stuart FOR:EX
> [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, November 09, 1999 3: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,
>
=== message truncated ===
=====
__________________________________________________
Do You Yahoo!?
Bid and sell for free at http://auctions.yahoo.com
----------------------------------------------------------------------
To unsubscribe from this list, send e-mail to [EMAIL PROTECTED] and put
"unsubscribe MAPINFO-L" in the message body, or contact [EMAIL PROTECTED]
