T.R | Title | User | Personal Name | Date | Lines |
---|
3344.1 | Did you change the data type for one of the fields? | CSC32::K_APPLEMAN | | Tue Jan 16 1990 11:43 | 20 |
| I don't have SuperBase Personal but do have SuperBase Professional so I
don't know how similar they are, but I would imagine that they are
basically the same.
When you say you are editing the file definition, do you mean that you
are selecting the "Edit File" from the pull down menu? (again, don't
know if this is how you edit the file definition in PersonL). If so,
it sounds to me like you may have accidentally modified the data type
for one of the fields. For example, if you, by mistake, changed the
data type of a text field that contained alpha characters to a "number"
field, I believe that SuperBase will give you the error you described
when you try to access the file. I do know that it will not allow an
alpha character to be in a numerical field.
If this is the case, recovery would be simple. Just go into EDIT FILE
mode and check the field data types to be sure they are compatible with
the data that is stored in them.
Ken
|
3344.2 | That's what I though but... | PGG::MYERS | | Tue Jan 16 1990 13:04 | 16 |
|
AH HA! That's just it. I thought that I accidently changed the
definition of one of the fields, as you suggest. But (using the
pull down menus) when I went to Edit File I got the same "bad data"
message.
I then quit Superbase altogether (back to the Worckbench window)
and restarted it. Nothing. When I try to Open File I get that
#%*! error message!
Is the actual data in an ASCII format? If I could look at the raw
data perhaps I could reconstruct the file description.
Eric
|
3344.3 | If Def. file is corrupt, try replacing it. | CSC32::K_APPLEMAN | | Tue Jan 16 1990 13:28 | 19 |
| Sounds like the definition file itself is corrupt. This is actually a
separate file, but I don't recall what it's extention is. I think it
is xxx.sbf. Will check it out tonight. If it is corrupt and you do
not have a backup to restore it from, here's what I would suggest.
1. backup your current disk and set it aside.
2. using a new data disk, create a new database file using the same
fields and data types as the original database and give the database
the same name.
3. using a disk utility or the CLI copy the definition file from the
new data disk over to the original data disk. Do not rename it.
This will replace the original definition file with a good one.
This SHOULD work. When I get home tonight, I'll verify the file name
of the definition file and try it myself on a test database. I might
even try corrupting a definition file to see the effects and try to
recreate your problem..
Ken
|
3344.4 | Didn't work out too good. | CSC32::K_APPLEMAN | | Tue Jan 16 1990 20:34 | 9 |
| Well, I tried corrupting the definition file (by the way it is the
xxxx.sbd file) and all I accomplished was (believe it or not) to
corrupt the file. Got a Read/Write error when trying to open the
database. Apparently the sector editor I was using didn't write the
checksum correctly back to disk. So I guess I won't be much help.
Still sounds like it's the definition file that's giving you the
problem.
Ken
|
3344.5 | FYI | BONKER::DUPRE | The Sherrif of Noting-ham | Wed Jan 17 1990 09:27 | 8 |
|
I have Superbase Personal and Professional. The manual states
that the data in a field will be changed to the appropriate format
when the data type is modified and gives a table of what gets changed
to which and when.
Jim
|
3344.6 | What the manual says and what the program does... | CSC32::K_APPLEMAN | | Wed Jan 17 1990 11:11 | 8 |
| When I tried changing the data type to something incompatible with the
data entered (like the original data contained alpha characters and I
changed the data type to numerical) all I got was "####" characters in
the data filed. I don't see how it could possibly change alpha data to
numeric. Please give the page in the manual where you saw that. I
would like to investigate it some more and do some experiments.
Ken
|
3344.7 | Try this | BONKER::DUPRE | The Sherrif of Noting-ham | Thu Jan 18 1990 08:59 | 8 |
| Ken,
I don't have the manual with me but, obviously, if you try
to change an alpha field that contains a name, for instance, to a
numeric field the name data will not translate to a number that's
usefull. Try changing an alpha field that contains a number.
Jim
|
3344.8 | Has .0 solved his problem yet? | CSC32::K_APPLEMAN | | Thu Jan 18 1990 12:17 | 7 |
| Ok, I understand. There are so many ambiguous statements in the
manuals (ambiguous to me at least), I was wondering if this was another
of them.
re .0 - Have you solved your problem yet? If so, how.
Ken
|
3344.9 | A lesson learned | PGG::MYERS | | Mon Jan 22 1990 09:42 | 12 |
| I made one last valiant attempt to recover the data that I had entered.
Assuming that there was a problem with the description file, I
re-created it in another directory on the same floppy, using the same
sequence of fields. I then copied all the data files to that
directory. Now when I tried to opened the file in this new directory it
opened without a problem, but did not associate the data files with this
file description even though the had the same name.
I the end I just gave up and started all over again. Lesson learned:
make backups often.
Eric Myers
|