• State Verified Answer
  • +1 person also asked this people also asked this
  • Replies 13 replies
  • Subscribers 63 subscribers
  • Views 7505 views
  • Users 0 members are here

PW Admin table conversion error after update - 08.11.11.590 to 10.00.02.99

Sean Keene
Offline

After a successful DMSCONV of projectwise database I am getting the error in the screenshot below.  I have also attached log files from the DMSCONV, dmskrnl, and pwadmin.  The issue seems to be coming from the spatial tables.  Any help is appreciated.

LogFiles.zip

Parents Reply Children
  • 0 Offline in reply to Sean Keene
    are you sure? there should be a hell of a lot more messages if the logging level is set higher.

    in pwadmin.log.xml check the setting for:
    <!-- Messages related to file transfer operations. -->
    <category name="pwise.ft"> <priority value="warn"/></category>

    I would set the priority value to "all" and re-run your test.

     

  • 0 Offline in reply to Kevin van Haaren
    Yes sir. Scroll down in the log file to about the 2:41 am line. That is when I set the debug level ="all". You can see that is where the .hook and .netapi.discovery (of course alot more is reporting but just those 2 as examples) lines are reporting more than there usual debug info.

    I did perform a test upgrade on a VM about a week before this and did not receive the errors. I received these errors on the production environment and then reset when I could not figure it out. I will perform the upgrade again once a solution has been found or reported to me.

    Again, I appreciate your response.
  • 0 Offline in reply to Sean Keene
    What is the status of your "Documents\dmsSystem\Spatial\Root folder where DPR files used as background map layers are stored\" folder in PW? That is where it attempts to place the world.dpr file. If that folder, its permissions, or storage area where it resides are not proper, it might throw this error.
  • 0 Offline in reply to Sean Keene

    whoops, my bad, didn't read down far enough. File upload fails sending file to server bentley2016.banning-eng.local trying to store it on that server at D:/pwstorage/projects/d0109232/world.dpr.

    it gets a ip address for the server so that's ok, it seems to send the file ok. so i would verify the path it's trying to write to exists and has appropriate file permissions for the account that your pw server is using.

    2017-06-04 02:42:16,125 INFO [0x00003b50] pwise.ft - dmsFTSendFileToServer(0x1, 'bentley2016.banning-eng.local','C:/Program Files (x86)/Bentley/ProjectWise/bin/world.dpr','D:/pwstorage/projects/d0109232/world.dpr')

    Bentley might have more details if they could tell us what error -11040 was.

     

  • 0 Offline in reply to Kevin van Haaren
    Response to MWr and Kevin,

    I checked the storage area and folder where "Documents\dmsSystem\Spatial\Root folder where DPR files used as background map layers are stored\" points to, which is folder id "D:/pwstorage/projects/d0109232" and the file world.dpr already exists. The access control is set correctly on that folder or no restrictions on file creation.

    After combing the log file a bit more, it is interesting that this error comes up "pwise.server - Error 100 "select o_csid,o_name from dms_coordinatesystems AS a where 1 >= (select count(*) from dms_coordinatesystems AS b where b.o_csid >= a.o_csid)" reported at func: dmdSpatialSRSListSelect line: 3057" shortly before the pwise.ft error comes up. Even stranger is that throughout the log file the pwise.database and pwise.spatial.schema.validation which is what the original PWAdmin error was complaining about "Spatial tables creation failed" does not report an error.

    If the upgrade is expecting the file world.dpr to not exist that could be the issue but I am not for sure.
Communities
Support and Services
Training and Learning
Social Media