input error when reading a case

[Tanya Temkin]

I started work on my file this morning (a saved file I opened with GET
FILE),  tried first to do a simple "sort cases by XXXX" and got the
following error message:
>Error # 1400.  Command name: sort cases by
>Input error when reading a case.
>This command not executed.

Any changes made to the working file since 17-AUG-2007 15:19:58 have been
lost.
The time now is 09:55:49.

3:19 yesterday afternoon was last time I saved file.
I get this error message if I try to sort by any variable or create a new
variable, or try to run frequencies - including part about all changes to
working file having been lost since 15:19 on 8/17.

I tried making copy of file and working from copy, moving file to my local
drive from shared drive - same problem.
I'm using V 14. The file was created using 14. It has about 178,000 cases.
If there's a "bad case", how can I tell which one it is?

I saw an old post in archives about this using N OF CASES as a diagnostic
, but I'm not too sure how this works.

I guess at worst I will open previous version of file before I made lots
of transformations and just run all my syntax again...

Thanks
Tanya

Tanya Temkin
Research Associate
AACC Reporting
Northern California Regional Office
The Permanente Medical Group
[phone]
TIE 8-428-6680


NOTICE TO RECIPIENT:  If you are not the intended recipient of this
e-mail, you are prohibited from sharing, copying, or otherwise using or
disclosing its contents.  If you have received this e-mail in error,
please notify the sender immediately by reply e-mail and permanently
delete this e-mail and any attachments without reading, forwarding or
saving them.  Thank you.

[Richard Ristow]

This'll be really quick.

At 01:27 PM 8/18/2007, Tanya Temkin wrote:

>I started work on my file this morning (a saved file I opened with GET
>FILE),  tried first to do a simple "sort cases by XXXX" and got the
>following error message:
>>Error # 1400.  Command name: sort cases by
>>Input error when reading a case.
>>This command not executed.
>>
>>Any changes made to the working file since 17-AUG-2007 15:19:58 have
>>been lost. The time now is 09:55:49.
>
>3:19 yesterday afternoon was last time I saved file.
>I get this error message if I try to sort by any variable or create a
>new
>variable, or try to run frequencies - including part about all changes
>to
>working file having been lost since 15:19 on 8/17.

Yes, that looks pretty diagnostic of a corrupted saved file, though
others may have alternative thoughts.

>I tried making copy of file and working from copy, moving file to my
>local drive from shared drive - same problem.

That suggests the corruption is on the SPSS level. That is, it's a
valid DOS/Windows or whatever file, but its internal structure doesn't
match SPSS's standard for a saved file.

Copying it with system utilities would create a new file, equally valid
file on the system level, with the same invalid structure on the SPSS
level.

To start at the end,

>I guess at worst I will open previous version of file before I made
>lots
>of transformations and just run all my syntax again...

I'd seriously consider doing this, rather than playing a lot with
diagnostics. The best diagnostics and tricks, at least those I know,
have no more than a fair chance of succeeding, and would probably take
longer than rerunning the syntax. (Or, will it take a long time? It is
it a lot of programs, that need to be run in sequence? But if that, it
may be even more important to re-run, saving all intermediate steps.)

If the new saved file shows the same problems, you've got something
fairly deep going wrong between your syntax and SPSS. It would almost
*ipso facto* be an SPSS bug - at least, no application should create an
invalid version of its own files, no matter how bad the input it's
given.

Stepping back again,

>I'm using V 14. The file was created using 14.

It may be neither here nor there, but have you installed the 14.0.2
patch? I've no reason to think that would matter, but it's wise to be
current.

>  It has about 178,000 cases.

Upper-modest size at most, by current standards. Far too small for size
to be a problem.

>If there's a "bad case", how can I tell which one it is? I saw an old
>post in archives about this using N OF CASES as a diagnostic, but I'm
>not too sure how this works.

That may have been mine. And it may be useful; or not, even if it
works. Again, the easiest and most reliable approach may be to
re-create the file. But, it works like this:

N OF CASES <value>.
GET FILE=<problem file>.
FREQUENCIES <something>.

For "<something>", choose a variable whose frequency table will be
short, and if possible illuminating. For "<value>", experiment with
values shorter than the number of cases in the file, perhaps by binary
subdivision. Start, though, with a very small value, like 10. If it
can't read one case, that's more or less complete corruption; if it can
read half but not 3/4 of the file, something odd happened in the middle
(the strangest occurrence); if it can read all but one of the cases,
some accident at the end.

But knowing the answer may not help much, though it would be very
useful to anyone chasing the problem down as a possible SPSS bug.

Another thing I've suggested sometimes:

GET FILE=<problem file>.
SAVE OUTFILE=<separate copy>.

That is, make a copy at the SPSS level, not the system level. That
*may* be a little more robust, in fixing the file. But it could very
well fail the same way.

You could also try,
GET FILE=<problem file>.
XSAVE OUTFILE=<separate copy>.
EXECUTE.

That *may* tell you how far SPSS gets, in the problem file: how many
cases are saved in "<separate copy>"?

But at best, these are 'maybe's. Consider, whether it isn't better just
to re-create the file.

-Best of luck,
  Richard

[Tanya Temkin]

Richard,

Thanks for the comprehensive (but not too hopeful) answer. SAVE OUTFILE
failed too. Given all the uncertainties with trouble-shooting and fact
that running syntax again will take a matter of minutes (it's all been
tested in setting up previous file) I'll just re-create file. This
confirms that I should continue my practice of saving successive separate
versions of files as I do more and more transformations...less syntax
needs to be run again than if I have to re-run from square one.

Previous file is working fine! For now....

Regards
Tanya

NOTICE TO RECIPIENT:  If you are not the intended recipient of this
e-mail, you are prohibited from sharing, copying, or otherwise using or
disclosing its contents.  If you have received this e-mail in error,
please notify the sender immediately by reply e-mail and permanently
delete this e-mail and any attachments without reading, forwarding or
saving them.  Thank you.




Richard Ristow <[hidden email]>
Sent by: "SPSSX(r) Discussion" <[hidden email]>
08/18/2007 11:26 AM
Please respond to
Richard Ristow <[hidden email]>


To
[hidden email]
cc

Subject
Re: input error when reading a case






This'll be really quick.

At 01:27 PM 8/18/2007, Tanya Temkin wrote:

>I started work on my file this morning (a saved file I opened with GET
>FILE),  tried first to do a simple "sort cases by XXXX" and got the
>following error message:
>>Error # 1400.  Command name: sort cases by
>>Input error when reading a case.
>>This command not executed.
>>
>>Any changes made to the working file since 17-AUG-2007 15:19:58 have
>>been lost. The time now is 09:55:49.
>
>3:19 yesterday afternoon was last time I saved file.
>I get this error message if I try to sort by any variable or create a
>new
>variable, or try to run frequencies - including part about all changes
>to
>working file having been lost since 15:19 on 8/17.

Yes, that looks pretty diagnostic of a corrupted saved file, though
others may have alternative thoughts.

>I tried making copy of file and working from copy, moving file to my
>local drive from shared drive - same problem.

That suggests the corruption is on the SPSS level. That is, it's a
valid DOS/Windows or whatever file, but its internal structure doesn't
match SPSS's standard for a saved file.

Copying it with system utilities would create a new file, equally valid
file on the system level, with the same invalid structure on the SPSS
level.

To start at the end,

>I guess at worst I will open previous version of file before I made
>lots
>of transformations and just run all my syntax again...

I'd seriously consider doing this, rather than playing a lot with
diagnostics. The best diagnostics and tricks, at least those I know,
have no more than a fair chance of succeeding, and would probably take
longer than rerunning the syntax. (Or, will it take a long time? It is
it a lot of programs, that need to be run in sequence? But if that, it
may be even more important to re-run, saving all intermediate steps.)

If the new saved file shows the same problems, you've got something
fairly deep going wrong between your syntax and SPSS. It would almost
*ipso facto* be an SPSS bug - at least, no application should create an
invalid version of its own files, no matter how bad the input it's
given.

Stepping back again,

>I'm using V 14. The file was created using 14.

It may be neither here nor there, but have you installed the 14.0.2
patch? I've no reason to think that would matter, but it's wise to be
current.

>  It has about 178,000 cases.

Upper-modest size at most, by current standards. Far too small for size
to be a problem.

>If there's a "bad case", how can I tell which one it is? I saw an old
>post in archives about this using N OF CASES as a diagnostic, but I'm
>not too sure how this works.

That may have been mine. And it may be useful; or not, even if it
works. Again, the easiest and most reliable approach may be to
re-create the file. But, it works like this:

N OF CASES <value>.
GET FILE=<problem file>.
FREQUENCIES <something>.

For "<something>", choose a variable whose frequency table will be
short, and if possible illuminating. For "<value>", experiment with
values shorter than the number of cases in the file, perhaps by binary
subdivision. Start, though, with a very small value, like 10. If it
can't read one case, that's more or less complete corruption; if it can
read half but not 3/4 of the file, something odd happened in the middle
(the strangest occurrence); if it can read all but one of the cases,
some accident at the end.

But knowing the answer may not help much, though it would be very
useful to anyone chasing the problem down as a possible SPSS bug.

Another thing I've suggested sometimes:

GET FILE=<problem file>.
SAVE OUTFILE=<separate copy>.

That is, make a copy at the SPSS level, not the system level. That
*may* be a little more robust, in fixing the file. But it could very
well fail the same way.

You could also try,
GET FILE=<problem file>.
XSAVE OUTFILE=<separate copy>.
EXECUTE.

That *may* tell you how far SPSS gets, in the problem file: how many
cases are saved in "<separate copy>"?

But at best, these are 'maybe's. Consider, whether it isn't better just
to re-create the file.

-Best of luck,
  Richard