I have code like:
dbSave(cvid_org libName cellName viewName) ,
which works fine within dfII 5.1* release even when the target cell view (libName:cellName:viewName) is open for edit in the current session. Basically, it just overwrites the current target cellview with the contents in cvid_org. As the result, I will see both disk and display window of the target cellview are updated.
However, in the dfII 6.1 release, this same code works correctly ONLY when the target cell is not open in the same session (memory) for edit. Otherwise, it complains "dbWriteCellView: Unable to lock database file for libName/cellName/viewName" and fails. Sounds to me that the same API will not be able to handle memory anymore: it couldn't figure out that the target cell is in memory in EDIT mode and it has the "lock" already.
So, I am using a ugly work-around: adding "dbPurge" first in my script to remove the target cell from memory and then, run the same dbSave, and reopen it after that.
Do you have any clue why its behavior should change to the new way? Do you have suggestion for better work-around?
The OA database itself sets a "in use" flag when a cell is opened for edit. Virtuoso cannot override the flag.Try to change the mode on the cellView to read only (make it non editable, you may have to discard edits first) and then save the data.
Unfortunately that doesn't work either - it says:*WARNING* (DB-270236): Cannot save to cellview 'amsPLL/blah/schematic'; the cellView is opened read-only.
which is not very helpful. I think closing (purging) it is the only option at the moment (I tried "s" mode too (but that's really read in disguise)).
Can't use dbCopyCellView, because it tells you:
INFO (DB-170007): dbCopyCellView: amsPLL/blah/schematic already in VM. No copy being done.
Thanks for correcting me, I do not have access to Virtuoso to test my suggestion.
Sorry Ted - I guessed you'd not had the chance to try it. By coincidence I was looking into this at the same time as you, that was all.