Migrating Private Views

I am using a script agent to attempt to migrate private views that are stored on the server to another user.  The script  changes the view's 'Readers' field with the other user's name.  After running the script, the view disappears and cannot be seen by anyone.  I have ckecked and double checked that I put the correct spelling of the user's hierarchical name.
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

if u use the script to change back to the original user then it works fine?
NetRatAuthor Commented:
Good question... I did try that and it seems that after I change the $Readers field in any way, I cannot recover the view and then no user can see it.  But, here's the weird thing, if I change the $Readers back to the original user, that user cannot view it but an agent that is run using that user's ID can access that private view and modify it.

I must be missing a piece to this puzzle.  What other differences are there between normal and private views?  I have dealt with access fields before and haven't had any problems (weii. the other access fields were all document related though).
Check the security tab of the view, see whose name is listed there before and (if possible) after the change.  Also try to remove the db icon from the desktop and add it again before checking.
NetRatAuthor Commented:
I will try what you recommended ghassan.

I will also award points to anyone that can tell me what the programmatic differences are between normal views and private views stored on the server.  It seems like it has to be more than just the $Readers field.
Private views stored on the server (they are actually shared, private on first use), are actually stored in the database.  But this depends on the security option 'Create Private Views'.  If the user has this option in the db's ACL then the private view will be stored in the db otherwise it will be stored in the user's desktop.dsk file, meaning his own workstation.  If any changes are made to this type of views, then the user must delete his local copy of the view and re-open the shared view, or he can also delete his db icon and put it again, for the changes to be seen.  This type of view is very suitable for customising views that use the @username.
Normal private views are stored on the user's desktop, and the programmer has no real control over them.
Shared views, are seen by all and stored in the db.


Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Lotus IBM

From novice to tech pro — start learning today.