Pdox4.0/DOS, Unexpected condition: File delete (i117)...(CODE 31)

Pdox4.0/DOS, Unexpected condition: File delete (i117)...(CODE 31)

Post by ThynkrT » Sun, 08 Feb 1998 04:00:00



Unexpected condition: File delete (i117) - C:\PDOX40\KENNEL\BOOKING2.M06 (CODE
31) -- Leaving Paradox

I'm running Paradox 4.0 in a standalone app on a 486/50 DX2 with 12 MB ram.  I
launch the app with - extk 8192.  I don't think it's a hardware problem, since
it also happens with my P133/16 MB.  One peculiarity was that I seemed to have
aquired some files that I don't recognize, to wit Booking2.m39, Booking2.t39
and Booking2.m44.  As an experiment I temporarily renamed Booking2, but those 3
files remained unchanged.  Since Paradox wasn't interested in them I got rid of
them.  Before doing so I looked at the contents.  ~.m39 & 44 were garbage
chars., and ~.t39 contained garbage, field names from Bookings/Booking2, and a
few scraps of data from two consecutive records in an entirely different table
-- Animals (pet name, breed, comments, feed instructions, etc. (I was able to
identify the records, and they appear to be complete).  The crash has occurred
several times and it doesn't seem to matter whether I'm running from DOS, Win
3.1 or '95.  TUTILITY finds nothing wrong with the Booking2 table, which is not
indexed, has 30 fields, 3 of which are memo type.  The crash always occurs at
the same line of the script, a delete query.  


  ADD "Booking2" "Bookings"
  Query

   Booking2 | Payment Form   |
    delete  | SKIP OR CANCEL |
            |                |

  Endquery
  DO_IT!

<screeeech-crunch>

Any ideas?  Thanks in advance.
No need to CC, I'll pick it up here.
--
I don't work at home, I live at the office.
ThynkrToo does not accept mail (spam-bounce) "rknyht" at aol does, but only
spelled backwards.

 
 
 

Pdox4.0/DOS, Unexpected condition: File delete (i117)...(CODE 31)

Post by Steven Gree » Sun, 08 Feb 1998 04:00:00


Thynker: the .m* and .t* files are temp files, from a data entry
session, that pdox won't even expect to find until the *next*
time it creates them..

Tutility's {Verify} option isn't worth running.. when in doubt,
make backups, then {Rebuild}.. if you *still* have the problem
after that, you have a badly damaged set of files..

Also note that the 3 memo fields should be the *last* fields in
the table.. seems to help with stability, especially if the memo
fields are heavily used..

--
Steve Green - Diamond Software Group - Waldorf Maryland USA

and Corel's CTech tech support staffs but I don't represent
Borland International or Corel in any official capacity.

 
 
 

Pdox4.0/DOS, Unexpected condition: File delete (i117)...(CODE 31)

Post by ThynkrT » Sat, 14 Feb 1998 04:00:00



Quote:>Thynker: the .m* and .t* files are temp files, from a data entry
>session, that pdox won't even expect to find until the *next*
>time it creates them..

Ah.  Got it, thanks

Quote:>Tutility's {Verify} option isn't worth running.. when in doubt,
>make backups, then {Rebuild}.. if you *still* have the problem
>after that, you have a badly damaged set of files..

Tut. 4.0 asks for a name, then makes a copy of the damaged table.  Do you
recommend greater measures than that?  I do file backups regularly but, since
damaged tables apparently can soldier on for a while, I suspect I might be
backing up some damaged files anyway.

Quote:>Also note that the 3 memo fields should be the *last* fields in
>the table.. seems to help with stability, especially if the memo
>fields are heavily used..

YYOWW!!  I started with Paradox for DOS 1.1 -- the app I've built has its roots
in those days.  Never knew the field placement might make a difference.  I
think I might have some work ahead of me.  Fussy, fussy work since I have a lot
of linked reports.

Thanks, Steve, glad I found this place.  I'll stay tuned.

--
I don't work at home, I live at the office.
ThynkrToo does not accept mail (spam-bounce) "rknyht" at aol does, but only in
reverse (thynk about it).

 
 
 

Pdox4.0/DOS, Unexpected condition: File delete (i117)...(CODE 31)

Post by Steven Gree » Sun, 15 Feb 1998 04:00:00


Thynkr: Tutility only writes out the "backup" table to disk when
it is too big to hold in memory.. so the majority of your
"backed up" tables don't get written back to disk until *after*
the rebuild is finished.. always make your own backups *before*
the rebuild..

--
Steve Green - Diamond Software Group - Waldorf Maryland USA

and Corel's CTech tech support staffs but I don't represent
Borland International or Corel in any official capacity.