Transaction cancelled - Error: Unable To Log Transaction (48)) attempting to frame the transaction

questions
1

Two weeks ago, one of my clients got this error:

‘Error: Unable To Log Transaction (48)) attempting to frame the transaction on WKProsjekt!PosGlass.’

After 6 hours, the error disappears.

Today, exactly 2 weeks after, a new error appears:

‘Error: Unable To Log Transaction (48)) attempting to frame the transaction on WKProsjekt!PosBeslag.’

And after 2 hours, the error disappears again.

First time, only the PosGlass table generates the error, and second time, only the PosBeslag table. They are both used in the same Form in a similar way. There are also four more tables in the same Form that works in the same way. And they are all in WKProsjekt.tps.

The application with this Form has been working without any problems for 10 years.

Does anyone have an idea what could be causing it?

2

Maybe the boss (or whomever) had a special window opened that locks the file, but they only come to work every 2 weeks or so?

3

The application runs on a remote external server, so it must be something the provider does.

4

I remember using multiple tables in a single file, used to be working nicely. But I also remember using a TCF file for managing transactions across the network. I can’t remember the detail but have a look in the Clarion help for “TCF”. Maybe by using a TCF file in the same folder as the TPS file, you’ll make some progress to solve it.

5

It happened again one week ago, but only for a few minutes. This time it was in another table in the same TPS file.

The application is on a remote server and it is not a local network. And the TCF file is in the same folder as the TPS file.

Another client running the same application in the same way never gets this error.

6

You could run into this problem if someone else was in a transaction and a window was open. The transaction locks the files.
Another cause, similar, is if someone is in a transaction and the system blows up, or they logout and leave the program running, or some other cause that basically leave an open transaction.
After a period it times out and can be released.

7

Do you use LOGOUT where transactions are created?

8

No, it’s a regular template form with several list boxes with child records.

9

no disk space or memory, or, table already locked.
Is this using the TPS driver?

10

Yes, it uses the TPS driver.

There is a lot of disk space on this server and there is 24 GB of memory, so it is not likely.

If the file was locked I don’t know, but I think if it was I would get another errorcode.

And there have been no transaction errors in the last 3 weeks.

Maybe I should have used Transaction Manager in this Form. Are there any examples of how to use it in a Form?

11

Maybe I should have used Transaction Manager in this Form. Are there any examples of how to use it in a Form?

not sure, i always did most of the data processing in source procedures using the logout/commit/rollback from the clarion language directly

12

Transaction Framing error 48 on a MEMORY driver table?

I have 3 ‘virtually’ identical procedures using 3 different single record memory files. 2 work fine, the other gives me an error 48 whenever data is changes. Click Continue and it saves fine.

Ideas?

13

Thanks Sean Hennessey…
For reference…
In my data dll (or your single exe): Global Props → Actions
→ Indiv File Overrides → select the Table → Properties
→ Use RI Transaction Frame → NO

14

Is the problem fixed now?

15

Yes - it is fixed. It would be nice of the templates didn’t generate Transactions for any driver that didn’t support it.

1 Like
16

The transactions are mostly done in the RelationManager methods. And I think the individual file manager is probably the one that sets “SELF.UseLogout” for the primary file – the templates set that to “Use default” (which you have had to chnage to “No”). I think you would really only run into problems if your primary file is able to use logout, but one of its related files is a different file type that you cannot add to the logout. And I think that’s up to you to specify – too much to expect of the templates.

17

Would be nice if the templates were smarter. Would be nice if I were smarter.

One page from the docs is good to keep in mind for memory tables.

imddDocs
imddDocs895×452 41.6 KB

18

I guess there are two levels of dealing with logouts. The first one of the code that the templates/and classes implement. There’s the UseLogout check in the relation manager methods, and that value comes from the relationmanager init, which will set UseLogout to False if you click No in the overrides, and True otherwise (Default or Yes override). It doesn’t have any driver-based variation.

The second level is what the driver does when it gets told to logout a file, or a list of related files. There are a bunch of drivers (dbase, foxpro, memory etc.) that don’t support logout. When the driver gets a logout request for a driver that doesn’t support logout I guess it has the choice of totally ignoring it (and the commit), or giving you a warning. Probably the warning is the better option.

Complicating things is that PROP:Driver is writable at runtime, so in theory you could, for example, set up a file as ODBC in the dictionary, and change it to the in-memory driver when you start your program. The template would have to base its writing of the Init method on your dictionary declaration, so would be wrong once you changed your driver.

1 Like