Hi you all,
We have a lot of mvba files ( 36 ) wich are used by our engineers, 12 workstations, al the mvba on a network share. MVBA is used to create drawings, ad cells to drawings, and count cells in drawings and create a csv file with the cell counts, for processing.
All this works, rather well.
Yesterday I discovered, that the dates on the mvba files keep changing by itself, started digging and found out the directory wasn't write protected as it was on the former server we used, so I changed it so that only I can write in the directory, since I think there is nothing in the MVBA files that need saving.
Unfortunatly this causes microstation to complain at startup, because the first thing it seems to want to do when any vba is executed, is save all the vba files. This results in a popup stating it can't save a mvba and if you want to save somewere else. 36 times. These popups have been nown to occur before, but before the whole row popped up just twice, first row of pop ups after te first mvba is called, and the second row by trying to close microstation with the cross at the right top. Then after microstation was restarted everything works.
Now since the rights for the directory are set to read only, there are several, not all, pc's that keep complaining the mvba can't be saved, wile the others just work
Could be a problem caused by the last or last before that update of Microstation ( were running V8i select 08.11.09.829 now) because all the mvba files used to be on a totally write protected server. Or perhaps have something to do with the way Microstation is installed, since most of the pc here are replaced ( there are new pc's with the problem, and also new pc's without the problem.)
So now the question is, is this a setting I can turn of, or is this caused by the MVBA? And if it is the vba, how do I troubleshoot this?
But given the fact all the pc's work with the same mvba, from the same directory, and not all the pc's have the problem I think it must be a setting somewhere.
Any Idea's are greatly appreciated
Hi Leo van der Hoeven,
Can you confirm if you may be seeing the Microsoft Last Accessed Time vs. Last Modified Time stamp changed?
Using Microsoft Process monitor against MicroStation CONNECT Update 13.1 and having several .mvba projects in my autoload, I do not see any Write operations against the .mvba file extensions using this tool when simply loading MicroStation, entering a design file, loading the VBA project manager, then opening the Microsoft VBA editor (no changes to any items in any projects).
If you are seeing changes to the Last Modified time stamp, can you zip and attach a list of your MicroStation configuration variables?MicroStation key-in: SHOW CONFIGURATION.
Thank you,Bob
Hi Bob,
I can indeed confirm it is the last modified or even last saved timestamp.
I'm only having trouble with the SHOW CONFIGURATION. I tried it twice but noting seems to happen, probably a textfile made somewhere, but I can't find it. Do you know where to look?
When I key-in "show configuration" it automatically opens an instance of notepad.exe with the file open. If you do not see an instance of notepad.exe running with the file open, the file can be located (selected or opened) using one of these MicroStation key-ins:
Open Explorer in folder: $ % explorer $(MS_TMP) Select log file: $ % explorer /e, /select, $(MS_TMP)configVariables.txt Open log file: $ % notepad $(MS_TMP)configVariables.txt
HTH,Bob
I don't know why, but the "show configuration" doesn't work. It does not create a file. The other keyins work but can't find a file, and the is no file with that name on my system.
So I pulled a debug file from the installation, I hope it to contains what you where going to check.msdebug.zip
Thanks, Leo
It appears that you are running MicroStation v08.11 not MicroStation CONNECT v10. For future posts it certainly helps to see/know it clearly if using our recommended posting conventions. SHOW CONFIGURATION is MicroStation CONNECT's "live debug". The MicroStation V8i equivalent key-in to provide a "live debug" is:
mdl load calculat;calc mdlSystem_createCfgVarDump(); $ % notepad $(MS_TMP)summary.cfg
If you can generate that we can compare quickly if any variables could be causing different results.
It seems there was something going wrong with my last post, since I just discovered It isn't showing up here, wich is kinda strange cause I did see it here, but here it is again.
I had some trouble creating the summary files, because I got error messages saying the file could not be found. But as it turns out the file was created in a different spot. I'll insert it here:
summary- MS Leo.cfg
For comparison I pulled the file also from a colleges PC, one that doesn't have the problem. I tried to compare them, and there are some differences, but I don't now what to look for. I hope you find the problem.
The good pc's file:
summary (002).cfg
Thanks for the effort.
Leo.
Hi Leo van der Hoeven
Both configuration files appear to be relatively closely matching other than install locations, user names, and your having LUMENRT variables defined. So from a VBA/MACRO analysis both computers are configured the same.
My next thought would be for you to add MS_VBA_OPEN_IN_MEMORY=READONLY to your configuration to see if that can help ensure the .mvba file is immediately read, then should only accessed in memory from that point forward.
The next/last recommendation would be to consider capturing a Microsoft Process Monitor (procmon) log to help reveal the hidden actions we currently cannot see/detect from a product configuration perspective. This should help you indentify any 3rd party modules/dlls that may be loaded in the address space and changing/overriding otherwise normal behaviors.