Moritz Lennert wrote:
Will have to debug some more...
Have gotten a bit further. It seems that the problem is in
lib/db/dbmi_base/xdr.c with the readn function, when executing the
function read at line 40.
Glynn, any hints for futher debugging ?
Ick. It might be a protocol issue. Or
On 05/02/08 17:17, Michael Barton wrote:
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
Thanks Moritz.
I see now that it is even more complicated than I thought. A
different issue on Windows than on a Mac. The good news is that it
seems to work OK with a good file.
Michael
C. Michael Barton, Professor of Anthropology
Director of Graduate Studies
School of
Michael Barton wrote:
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields
between records AND use the '|' separator, I have trouble on my Mac.
However, if I fix the file so that all records have the same
number
On 06/02/08 19:03, Glynn Clements wrote:
Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs correctly
with the default values (i.e. '|' as seperator) or doesn't.
Not in the case of my Mac gui
Michael:
As an aside, the | character seems like an odd default separator
for data fields in GRASS. I suppose it's a holdover from the
ancient past. But the fact that this is also has meaning as a pipe
seems to make it a risky separator in general. What about switching
this to something
Helena Mitasova wrote:
I did few more experiments (with a different file, but still
generated by GRASS - this time using v.out.ascii)
and it indeed looks like the fs=| is responsible
for the truly erratic behavior - I think that without quotes it is
represented as
pipe(?) so depending on
On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:
On 05/02/08 06:00, Michael Barton wrote:
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields
between records AND use the '|' separator, I have trouble on my
On 05/02/08 16:08, Michael Barton wrote:
On Feb 5, 2008, at 5:44 AM, Moritz Lennert wrote:
On 05/02/08 06:00, Michael Barton wrote:
Hi Helena,
It looks like the '|' is partly to blame, but not entirely.
If I use the original file with missmatched numbers of fields between
records AND use
On Feb 5, 2008, at 8:48 AM, Moritz Lennert wrote:
I would rather guess that depending on how the command line was
formulated, i.e. where the fs=| is placed, the command runs
correctly with the default values (i.e. '|' as seperator) or doesn't.
Not in the case of my Mac gui crash.
Michael Barton wrote:
I've run into a problem running v.in.ascii for WinGRASS importing an
ASCII points file. Sometimes it works OK. Other times, it causes a
Windows dbf.exe error but still gets the job done. In most cases, it
causes a dbf.exe error and only imports the first point--with a
On Feb 4, 2008, at 7:23 PM, Hamish wrote:
Michael Barton wrote:
I've run into a problem running v.in.ascii for WinGRASS importing an
ASCII points file. Sometimes it works OK. Other times, it causes a
Windows dbf.exe error but still gets the job done. In most cases, it
causes a dbf.exe error
I just emailed you the response - it is the fs=|
try to skip it to see what happens. It does not seem to have anything
with the data in the file
Helena
Helena Mitasova
Associate Professor
Department of Marine, Earth
and Atmospheric Sciences
1125 Jordan Hall, Campus Box 8208
North Carolina
I did few more experiments (with a different file, but still
generated by GRASS - this time using v.out.ascii)
and it indeed looks like the fs=| is responsible
for the truly erratic behavior - I think that without quotes it is
represented as
pipe(?) so depending on where you put it you get
14 matches
Mail list logo
