ArcGIS 8.3, Attribute table join returns null values in data fields
jon_norstog
I have been hacking the Y2K Census at the census block group level
where I work. I don't have much of a DB program (choice of Access or
Excel), so have been using ArcGIS 8.3 to get my data out of the state
stf3 files.
What has worked in the past is to put together a shapefile of the
black groups and make sure there is a field that can be used to link
to the state Census files. The latter are about 8700 rows in a .dbf
file ... only 7 of those rows are the "right" ones. They are uniquely
identified in a field titled "LOGRECNO."
I had to figure which rows were the "right" ones. In the stf3 files,
there are three separate entries for each block group, on of which is
the official value, one of which may or may not be the actual count,
another which may or may not be the imputed amount added to the actual
count. Sometimes, I think it is for those valus that were collected on
the "short form, all 3 values are the same.
When I used a field based on the block group number (STFID in the
Esri data CDs I used to select out my block group shape file) my joins
would work but would often extract the wrong data - because there were
three separte entries with the same number in the STFID i hacked into
the Census files.
Long story.
Anyway I started doing my joins based on the "LOGRECNO" field. The
joins work, but all the cell values are replaced by <null>. When I go
back to the corresponding row in the .dbf version of the stf3 file,
there are values in those cells.
This does not occur with all of the .dbf files. It works with some,
doesn't work with others. It's driving me nuts.
For some reason ArcGIS is stripping all those values when it performs
the join. Has this happened to anyone else? How did you deal with
it?
TIA
jon norstog, planner
Shoshone-Bannock Tribes
jon_norstog
Well, no response on-list but I did hack away at the data. The
problem seems to come from the process of converting the Census bureau
downloads into MS Xcel files, then using Xcel to convert the files
into .dbf format.
A few gotchas: You have to adjust the column widths so that all
entries are completely visible, or else they are truncated in the .dbf
conversion. Also you have to check the cell format (general, numeric,
text) which sometimes mysteriously changes during the multiple
conversions required to use the census data.
You can use the MS software to hack up the Y2K US Census, but it
requires a lot of cleaning before it will work, and even then ...
What I would give for a simple, no-nonsense, command line,
boolean-operator data base!
jn
thur...@allidaho.com (jon_norstog) wrote in message news:<f9b3265.04082...@posting.google.com>...
David Drum
> What I would give for a simple, no-nonsense, command line,
> boolean-operator data base!
You mean like MySQL? Or Postgres?
Regards,
David
jon_norstog
Exactly. I did download the current MySQL binaries for Windows, they
don't let you just address a DB file in a directory, you have to have
a server-client relationship, even if its a virtual one on a single
machine. I hacked away at it a while but something in the program
prevented Windows from shutting down and I ended up un-installing all
the MYsql binaries.
I may take some time and learn the software on Linux, where it is
better-developed, then go back and troubleshoot the Windows binaries.
But my favorite command-line boolean operator DB program is Info.
Thanks for your interest & comments
jn
David Drum <qn...@zber.arg> wrote in message news:<slrncl76om...@cynosure.local>...
David Drum
> Exactly. I did download the current MySQL binaries for Windows, they
> don't let you just address a DB file in a directory, you have to have
> a server-client relationship,
Jon,
I would suggest seeing if there is a Windows version of Berkeley DB.
That does not require a client/server relationship. Check SleepyCat
software; I believe they are active in or responsible for maintaining
Berkeley DB. I do not know if it supports SQL though. Probably not.
Regards,
David