DGN files getting corrupt/reverting to blank

In the last one month, this has happened about 5 times.

User would open a DGN file, which was previously worked on, and the file would be completely empty, like it's a new file.

Since the phenomena is rare, and apparently there is no pattern to it, it is causing headaches for me.

Our network is mostly Windows 7 professional computers with some Windows 8 computers, all patched and updated.  Server is server 2008 running on ESXi.

4 out of 5 times this problem has happened with remote users, working off of the VPN.


Has anyone run into a similar situation before or has any insights?  Any help would be appreciated.  Thanks.

Parents
  • What is the version of MicroStation being used? This can be important as only current versions would be certified and supported on Windows 7 or 8 systems. Also, we would not suggest opening files "live" over a VPN connection. This type of connection can be quite slow and problematic which could cause corruptions in your design files if editing "live". It would be suggested they copy the file locally to be edited from their local system drive rather than over a VPN connection.

    Regards
    Andrew Bell
    Technical Support
    Bentley Systems

  • @Andrew Bell: Microstation version being used is Version: 08.11.09.459.  Yes, your hunch has merit.  I've been considering the same thing but I cannot call the VPN a culprit so easily though since users on my network have been opening and working on files on VPN for a long time.  This just started happening.

  • I work with stormtrooper.

    It is a mix of 8.11.09.357 and 459, with the Win8 users on 459. Compress File on Exit is unfortunately mixed. So far it seems like it is about half and half, maybe pushing a little towards Compression on Exit turned on.

    I would love to have Design History turned on for everything, as it would make troubleshooting this much easier, but unfortunately from my understanding of it, the designers hate having to fill it out all the time, and are the main opposition.

    What is it about Compress File on Exit, other than a lost network connection during the exit, that would cause a problem like this?

  • Compressing files on exit across network is a workflow that has been found to cause file corruption.

    When you have "compress on exit" enabled, MicroStation creates a temp dgn-compress file in the same folder as the active drawing as defined by the variable $(_dgndir).  It then deletes the original file and renames the dgn-compress to  the same as the original. If this process is not completed due to interruption during the save process this can lead to file corruption.



  • Hi All,

    I work with stormtrooper and have seem to of lost 3 out of the 5 drawings. I am on Win 8 pro and V08.11.09.459. I have compress on exit turned on.

    I lost 2 of the drawings over the VPN connection and one while working in the office.  We have been using the VPN for several years now and discourage (we yell at people as this causes nothing but problems) from pulling them down locally and then uploading.

    One drawing I dropped the VPN while I was closing Micro. The second and Third, there was no connection loss.

    When I go back to open the drawing, I see the preview as if nothing is wrong and there is a size to the file, but there are no objects in the file. It's like it reverts to the original created drawing. We use a seed file to load some text and a few things into the drawing when its first created.

    If you have any suggestion, that would be wonderful. If you want me to check anything on my setup, I can do that too.

  • If a dgn-compress file is left over, presumably by a dropped connection or crash, or user error, would the existence of the dgn-compress file interfere with the creation of a new dgn-compress file later, when it is reopened by someone with Compress on Exit turned on, or does Microstation account for that and delete the leftover dgn-compress?

  • The file should be removed; the fact that it remains indicates a potential problem with the compression process. This is a potential issue when compressing files over the network and why this is not advised. If this file is still present you should be able to remove this file manually.

    Compressions should be done manually when there is not a potential for interruption of the process.



Reply Children
No Data