Error 1355 in Module 19 during Restore

vmtaylorvmtaylor Member Posts: 16
Hi

I am restoring data from a 3.6 database into 3.7, something I have done numerous times without a problem.

I am now getting the Error 1355 in Module 19 about 75% through restoring the keys on the Audit Trail table.

I have not directly modified the Audit Trail table so am not sure why it would fall down here.

I have searched the forum on this but not found a similar issue.
Does anyone have any ideas what the problem may be and a possible way round it?

Thanks!

Comments

  • Timo_LässerTimo_Lässer Member Posts: 481
    Have you really searched this forum?
    I found 13 topics when I search for "1355":
    http://www.mibuso.com/forum/search.php? ... words=1355

    Error Description: #Err_DBM_NotReentrant
    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.


    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).
    Timo Lässer
    Microsoft Dynamics NAV Developer since 1997
    MSDynamics.de - German Microsoft Dynamics Community - member of [clip]
  • vmtaylorvmtaylor Member Posts: 16
    I did search the forum!!
    There were lots of articles but couldn't see any that seemed a similar problem, i.e. during a restore.
    Now you have pointed it out tho.....! Sorry!!! :oops:
    Thanks for your help!
  • ManoMano Member Posts: 2
    I had the identical error (Internal Error 1355 in Module 19) when trying to Restore an Incadea database (which is based on the Navision platform) and the solution was as simple as making sure that the drive that the "TempFilePath" parameter in Tools/Options was pointing to had enough disk space. I found this solution on a Dynamics forum http://dynamicsuser.net/forums/p/64109/64109.aspx.
Sign In or Register to comment.