Internal error 1355 in Module 19

Firoz

Can anyone explain Internal error 1355 in Module 19 ?

pdj

Try searching for 1355 in the forum...

Timo_Lässer

#Err_DBM_NotReentrant

I could get the following informations about this error:

The way this error is provoked is the following:
1) Client issues a db request (which sits in queue on the server)
2) Client doesn't get a response in a timely manner (because the server is either busy with this queue or with something else)
3) Client re-issues the same db request
4) Server says "why do you want the same?" = "non-reentrant code"
The reasons are usualy:
a) the delay between client and server. I have seen it at a big installation when doing a restore (or changing/redesigning table objects) as client server.
When doing the same as client only (on the server) everything was OK. Additionally you must not re-design table on running system
(while old table objects might be in object cache of some other clients) - you may corrupt the database.
b) the server is busy responding this or other requests.
This may be a performance issue and you need to let us know if that is standard code or added functionality.
In both cases, wrongly selected key or poorly structured SIFT fields and keys are most likely to be the problem.

You'll get the error message when a particular piece of code in the database manager is called twice (probably from two different processes).
This errror is generated deep down in the database manager and can be caused by programming.
But it is a temparamental error that may not appear next time you try to run the same process.

Somebody has fixed this problem as follows:

I could fix it using two "solutions":
a) Deactivate the secondary keys (table item posts and BIG tables).
Run the Backup using the Navision client.
Restore the objects only.
Restore the Data
Activate the keys.
b) Set the DBMS Cache value (Tools --> Options) to a high value (e.g. 550000).
Commit Cache =NO
TempFilePath = e:/temp

Make sure that you will have enough disk space in a different partition than the S.O.
(if you Nav DB is 10 GB, the E: partition should be greater than 10 GB).

I hope this is helpfull for you.

kriki

Timo Lässer is correct.
I had the problem when renaming lots of values in the DB. The worst part of this error was that it did a COMMIT! So I had to restore the DB and lauch again.
The error occurred as well with a DB-server as with a direct connection with the client.
To make it work well, I just disabled some secondary keys and I didn't have the error anymore.