Content Center: Make local logins STOP CACHING data!!!! SERIOUS BUG!!!!

[dick_upton]

I am relying on a server based custom Content Center . . . I am the only Content Center Admin, the other only user is set up as a Content Center Consumer.

This problem manifested when I made changes to the server custom library, and the user's dialogues didn't comply to the new key defiinitions in a family. I also noticed that my updates to the templates of families weren't showing up in instances he was creating.

I went with my first instincts and played with logins to see if cache files were being called upon instead of Content Center files.

Lo and Behold, there is a folder of cache files which take precedence over the server's information. THIS IS NOT GOOD!!

The folder is
Documents and Settings\null\Application Data\Autodesk\Inventor 2010\{concent center server}\{Custom library name}\Families\ . . . and then there's a whole slew of XML and IPT files stashed away in here.

As soon as I blow away this Families folder in the offending users' Documents and Settings, life is good again - he sees the latest family information from the server. He can access the additional famiy members, and the key fields conform to the changes that I made to the server's custom library.

Now my question is: HOW DO I MAKE A SERVER-BASED CONTENT CENTER SETUP STOP CACHING FAMILY INFORMATION ON LOCAL MACHINES!!?!!? Ummm isn't it rather pointless to have a custom content library that everyone looks at, when each user seems to store an unsynchronized version of it locally?!?!

What this means is that, until this issue is resolved, for every time I add a family member or redefine a family template, or key columns, I have to go around and clear these cache folders on every users' login on every workstation. I don't have time to design all day and then go visit every coworker every time I make a slight change to the custom library


HOW DO I MAKE A SERVER-BASED CONTENT CENTER SETUP STOP CACHING FAMILY INFORMATION ON LOCAL MACHINES!!?!!?

[HallStevenson]

Heh, I guess that's one way to make Content Center "faster" !!

[jessicazhanxia.yan]

Hi,

I tried and found the other user could get the updates by "Refresh" manually. Have you tried with "Refresh" button when place from CC? Hope this could help.

thanks,
Jessica Yan(Autodesk)

[dick_upton]

Thanks for the reply Jessica, and no I was not aware of the function of the "Refresh" button. I'm sure it must work fine but . . .

This is a very dangerous thing, no?


Relying on the user to manually flush the local cache?? Is this normal function for a server-client relationship?! I don't think the user should get a choice whether or not they see the most current information from the server.

Now let's take this line of thinking to Vault in general:
Day 1: You are working on a design and you check it in. You are in sync with the server.
Day 2: Sam, the other designer, makes a change and checks the data in.
Day 3: You pull up your local version and release it. The shop builds to old data that you had stored locally. Day 4: Customer comes in and says, "I'm not buying off on this until you make the changes we talked about!!" The shop spends a week cutting it all apart and rewelding it. Your boss comes to you and says, "What the Hell happened, Jessica??? I thought Sam made the changes.

You say, it's ok, I just forgot to hit the Refresh button!?!?

Maybe I'm missing something here but that's just wrong.

[HallStevenson]

Use Task Scheduler, create a "task" that runs "Refresh Standard Components" on each user's machine. Problem is, "daily" is the most frequent option available....

[-niels-]

Can't you just let the cache reside on the server too?

If all users get the same generated models from the server and someone updates the CC and then refreshes the cache it should be less prone to wrong versions.

[dick_upton]

That would be a great solution but I think Content Center is dictating where the cache resides for each user - in that folder structure I layed out above.

But then again, what is the purpose of the cache in the first place besides
A) speed
B) speed
C) speed

So somewhere in the development of Content Center, it seems - pure conjecture here - a developer decided it was too slow to go get template file data for families each time, and to go get dialogue and key column data for families each time, so they figured the best solution was to generate these cache repositories on each users' login on the local machine. What they forgot to provide was an automatic refresh / resync. So it appears the only way to keep things in sync is MANUALLY (NOT GOOD).

Maybe I'm missing what you're suggesting Neils. Thanks for the input.

I believe this is an oversight on the part of the CC developers - Content Center shouldn't require manual resynchronization with the server databases. And I don't see any place in the interface to configure the user's cache location.

[-niels-]

I might be misunderstanding what you mean by cache, but i was thinking of where inventor generates the files for each CC item.

You can set this in the application options > file > default content center files.



But i do have to agree on the manual part, especially tedious when you have both pro and suite and some CC stuff is authored for tube&pipe... only the pro version can refresh those...

[dick_upton]

> {quote:title=-Niels- wrote:}{quote}
> I might be misunderstanding what you mean by cache, but i was thinking of where inventor generates the files for each CC item.

You can set this in the application options > file > default content center files.





Correct, you are misunderstanding what I mean by cache. I am aware of the default content center file location and how to control it. What I'm talking about is this secret little cache where Content Center is keeping stuff unawares to anyone, until a sync issue exposes the fallacy of the construct.

Go look for yourself. They are there. And you can't choose NOT to have them or where to put them.

[dick_upton]

Thanks Hall,

It sounds like you've had some experiences with this shortcoming as well. Can Task Scheduler be set up to run as a service in the background upon login?


Is this per Autodesk recommended workflow? Or is this a personal suggestion?

I appreciate your input.

[dick_upton]

Ok Jessica, I gave your MANUAL REFRESH thing a try.

I discovered an error in a few items in a part family and corrected them.

Then I opened Content Center in the "user"'s login, and hit refresh.


NO WORKY. The changes I made to the family did not appear in the user's Content Center.


My current ONLY WORKFLOW is to delete the cache folder which I discovered. This needs to be fixed before Inventor 2010 gets out of Beta (oh, snap!!)

[dick_upton]

I am going to need a long vacation if I can get all these issues resolved. This issue where local machines are BECOMING OUT OF SYNC WITH THE SERVER is a real GIGANTIC BUG!!!

I CANNOT rely on Content Center to display family edits on users' workstations when I am the only Administrator. I'm sorry Jessica but there has GOT to be a better answer than to:

- make a change
- run around to every workstation and hit Refresh.

This has GOT to be resolved professionally. Workstations MUST stay in SYNC with the server!!

[Anonymous]

Hello,

this behavior is certainly not expected. The Content center client should
discover automatically changes which were made on the server and download
latest version every time you make the change. What is happening here seems
to be isolated to your specific setting, setup or operating system state.
Please contact me on my e-mail michal dot hradil at autodesk dot com. We
will try to resolve the problem together.

Thanks, Michal

[AlexPetak_Autodesk]

Hello,

I have specific technical question:

In the very first post above you mentioned you current user path:

Documents and Settings\null\Application Data ...

I'm interrested about the null , because it should be your current user name.

Did you replace the user name with "null" for purpose of this post (to not reveal user name) or is this what you really see in the directory path?

Alex

[Michal_Hrcka_Autodesk]

Hi dick_upton,
This is a serious issue. It was no intent to use CC remote server this way. Server and client must keep in sync automatically without any user input.

We will definitely help you (and all others) to avoid that issue. Please share more information with me to help us fix that problem. If you want we can communicate directly. My email is Michal(dot)Hrcka(at)autodesk(dot)com

Information I need:
* what os are you (your coworkers) running on (XP,Vista, 32/64 bit)
* you mentioned admin user, normal user (did you mean ADMS user or windows user)

We are investigating the problem right now. If you have any questions or more information for us, please let me know via email.

Thanks,
Michal Hrcka (Autodesk Developer) Edited by: Michal_Hrcka_Autodesk on May 15, 2009 6:11 AM

[dick_upton]

Michal, you have mail.

[dick_upton]

Alex I tried to copy you on the email that I sent to Michal, but the address I guessed at was incorrect.

To answer your question, the "null" in the path statement is what the newsgroup did when I typed in the "{" character, then the word "name", then the "}" character - to symbolize the variable that is the local user's login name. The newsgroup parser converted it to "null".

If you wish me to send the same information to you as I did to Michal, please share your address with me or send me an email at dZiZcZk_upton@hotmail.com . . . remove the capital Z's.

[AlexPetak_Autodesk]

Thank you very much for your answer.

Regarding the e-mail, Michal (one or the other) will forward me the information internaly.
And I believe You will prefer to communicate just with one of us by e-mail to maintain the clarity.

It's perfectly OK if you send the email just to Michal Hrcka.

Regards,
Alex

[dick_upton]

I have an idea of putting a batch file into the login script to delete this folder when users' log in to their workstation. This may be a workaround until this bug is resolved.

[dick_upton]

All,

I would like to know if this bug is fixed yet? It would be nice to know if SP1 or SP2 of 2010 addressed this bug without doing testing here.