Strange TPS Lockup

questions
1

In all of my years of toiling over TPS files, I have never seen a situation such as this.

We have an application that uses TPS with superfiles as its current file format. The file is basically just a vehicle to get the data in and out of the app. When you load the file, it copies the records into corresponding IMDD tables, then all of the TPS tables are closed.

All of the data is saved to a new TPS file when saved.

I have dealt with quite a few TPS corruptions over the years, and have gotten pretty good at recovering data. This one situation, however, is a bit unique. The repaired file looks perfectly fine. It loads up into our app. The IMDD tables are filled. The TPS files are then closed. No errors detected.

However, after that bad file is loaded, the TPS file definitions in the app are in some kind of bad state that I do not know how to recognize. As soon as I try to set PROP:Name to one of the TPS tables, the app freezes. No crash, just freezes.

It doesn’t seem to matter “which” table I try to set PROP:Name on. It always freezes.

I checked STATUS(SELF.File), and all of the things I know how to check for. I made sure my &File reference really does point to the right file.

I wonder if anyone has any ideas on what might be going on here, or how to further diagnose the issue.

By the time this lockup happens, all of the tables are closed, and the originally loaded TPS file is gone. So I don’t think it is a file handle issue.

Thanks for any ideas or suggestions of how to recognize that a file might be bad when it seems good :slight_smile:

2

What Clarion version?
The only thing I can think of is a corruption in the compression of one of the records. When decompressed it goes too big and overwrites something critical to file opening.
Recent versions of Clarion have had some switches to guard against that a bit. Maybe turn on all the compile options and see if it catches anything.

3

This is C10.

The hang occurs before an OPEN() is even attempted. I will look at the compile options in the docs. Thanks.

4

I’ve only had a freeze with TPS files when I had the file open in Top Scan and I had changed a record and forgot to save the changes in TopScan.

I don’t know with a superfile if it is possible to see the individual states of the files in Explorer, but I suspect that one of the files might be locked? Maybe run your process and skip some of the steps before the freeze to see if you can eliminate it, or try with the debugger?

5

At the time that the freeze happens, there is no disk file to look at. All tables are closed, and pre-existing disk file (actually a temp file) no longer exists. There are no errors removing the temp file that was loaded. Everything seems A-Okay

Now that we’ve done our work with the data, I’m preparing the tables to receive new contents into a new disk file, so I use PROP:Name to assign the temporary filename + superfile. As soon as that line is hit, it just freezes. Same behavior as if someone hit a breakpoint in the debugger or something. No crash.

What I’m trying to do is figure out how to detect when this situation is encountered so it can be handled gracefully. Fortunately, I’ve only seen this once ever.

6

Might there be an illegal character in the filename?

7

I was just wondering that.

In working with AI and code I can’t begin to tell you the number of times that I have seen it slip in an “invisible” character or even change the BOM in a reply.

For Clarion that generally ends up resulting in some sort of bizarre error so far downstream that the error that Clarion reports is nonsensical (I might be working on line 100 of the CLW and it will report an error at line 3476 for example).

I generally beat on the AI and tell it ASCII only with no smart quotes, Unicode or BOM changes.

Then pay attention and keep in mind that if I get an error after an AI interaction about code and it is not an obvious syntax error that it was probably a stray character or similar misfire.

8

Whatever the original filename is, it is never seen by the Topspeed driver. It is a filename as commonly created by windows API to create temp filenames. But I will review it, just to make sure. Thanks.

9

Have you checked the PATH, or tried specifying the name with a full path?

Do you get the same problem if you try it with another file within the superfile, or another file that is not within the superfile?

Just guessing here?

10

It might be something like this, I would get problems I couldnt identify in TPS files, so what I did is I had an app which copied the data from one tps file to a new mirror copy, using the slow access:filename.insert method, and it would hang on the offending record, and then I could identify the problem record.

Copying everything out to a mirror tps file might be worth a shot.

11

It turned out to be one of the tables was “just a little bit” corrupted, even after tpsfix. It did not cause an error, but it apparently rendered any subsequent use of the Topspeed driver a lockup situation. Thanks for the suggestions.

3 Likes
12

Hi Jeff,
I wonder if the problem might have been easier to diagnose had you not been using a tps superfile? Just saying….. :wink:

13

Hmmm, I thought I read that the file didn’t exist? So now we can get TPS corruptions on non-existent files?

:thinking: :grinning_face_with_smiling_eyes:

Glad you got it solved!

14

I doubt that it would have been easier.

15

The file would get copied to a temp location, loaded into IMDD, one superfile at a time, then removed. It was at that time that there was no file existent.

HOWEVER

The most recent table had a corruption that still allowed the table to be opened without any errors.

Once that happened, the Topspeed driver was rendered inoperable. As soon as the app tried to access anything to do with a TPS file, such as setting PROP:Name, it locked right up.

But there was nothing that gave me a hint that this was a problem until the program froze.

If the “bad” table would not have been the very last one of the TPS file accessed, it would have been easier to glean what was going on. But since it WAS the last one, the app was able to keep on rolling happily until it needed to save the data. By then, that corrupted file was a distant memory, and it was obviously “fine” because it loaded. :slight_smile:

2 Likes