Bentley Communities
Bentley Communities
  • Site
  • User
  • Site
  • Search
  • User
ProjectWise
  • Product Communities
ProjectWise
ProjectWise Design Integration Forum PW Admin table conversion error after update - 08.11.11.590 to 10.00.02.99
    • Sign In

    • State Verified Answer
    • +1 person also asked this people also asked this
    • Replies 13 replies
    • Subscribers 64 subscribers
    • Views 7900 views
    • Users 0 members are here
    • administrator
    • Conversion

    PW Admin table conversion error after update - 08.11.11.590 to 10.00.02.99

    Sean Keene
    Offline Sean Keene over 6 years ago

    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

    • Sign in to reply
    • Cancel
    Parents
    • Kevin van Haaren
      0 Offline Kevin van Haaren Sun, Jun 4 2017 3:28 PM

      in the pwadmin log looks like it's failing to upload a file called "world.dpr" but it doesn't say where it is trying to upload it to. Might try boosting logging levels on the pwise.ft category to debug level and see it'll give more details.

      I checked my server and we don't have this file, but we only upgraded to 10.00.01.67. lots of changes in the 02.xx updates.

      pwise.dms - Error 100 reported at func: dmsSpatialSRSListSelect line: 1651
      pwise.ft - Error -11040 at func: FTnet_sendFile line: 752
      pwise.ft - Error -11040 "failed to send file to server" at func: putfile_proc line: 549
      pwise.spatial.schema.creation - CreateDefaultMap: Error creating "world.dpr" document

       

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Sean Keene
      0 Offline Sean Keene Sun, Jun 4 2017 6:45 PM in reply to Kevin van Haaren
      Thanks for the reply Kevin.

      The log file for pwadmin is a result of turning up the debug level.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Kevin van Haaren
      0 Offline Kevin van Haaren Mon, Jun 5 2017 9:57 AM 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.

       

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Sean Keene
      0 Offline Sean Keene Mon, Jun 5 2017 10:07 AM 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.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    Reply
    • Sean Keene
      0 Offline Sean Keene Mon, Jun 5 2017 10:07 AM 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.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    Children
    • MWr
      0 Offline MWr Mon, Jun 5 2017 10:26 AM 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.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Kevin van Haaren
      0 Offline Kevin van Haaren Mon, Jun 5 2017 11:30 AM 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.

       

      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Sean Keene
      0 Offline Sean Keene Mon, Jun 5 2017 1:40 PM 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.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Marty.Nickel
      0 Offline Marty.Nickel Tue, Jun 6 2017 1:10 PM in reply to Sean Keene
      turn up the dmskrnl.log files and try it again. that way we can see what it's erroring out on.



      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel
    • Sean Keene
      0 Offline Sean Keene Thu, Jun 8 2017 8:33 AM in reply to Marty.Nickel
      Ok, I will be attempting this again over the weekend.
      • Cancel
      • Vote Up 0 Vote Down
      • Sign in to reply
      • Verify Answer
      • Cancel

    Communities
    • Home
    • Getting Started
    • Community Central
    • Products
    • Support
    • Secure File Upload
    • Feedback
    Support and Services
    • Home
    • Product Support
    • Downloads
    • Subscription Services Portal
    Training and Learning
    • Home
    • About Bentley Institute
    • My Learning History
    • Reference Books
    Social Media
    •    LinkedIn
    •    Facebook
    •    Twitter
    •    YouTube
    •    RSS Feed
    •    Email

    © 2023 Bentley Systems, Incorporated  |  Contact Us  |  Privacy |  Terms of Use  |  Cookies