DSXchange

Hello Friends........

In our project....we have a couple of shared containers used as reference for different jobs...When we want to use a shared container we directly get a copy of it and insert in the job as usual... The jobs were working very well....

Recently..a problem started....Whenever someone is accessing a shared container..if any other person wants to access the same shared container...the job in which the shared container is used doesnt compile and shows an error in the shared container.....

The problem in detail............

Suppose the shared container used is SC1
If a DS programmer accesses SC1 in his job j1.....
IF another DS prgrammer designs a job j2 which has SC1 inserted in his job...at the same time
Now when they try to compile their jobs they cant....
BUT if they try compiling their jobs when no one else is accessing the shared container SC1 there are fine with the job....the job runs succesfully and no problems....

What might be the problem...In both the jobs the shared containers are used as lookups...Here the concept of shared container is not ompletely utilised...it is accessible but when it comes to compiling or running the job it is a problem.........
Are there any special instructions to follow before desiging a shared container....

Pls advise....

I wouldn't classify this as a 'problem', per se. If you open a Shared Container as if to work on it, it becomes locked just like a job would be. While it is open and locked, jobs that reference it cannot be compiled.

The solution is to only 'access' the shared containers like it sounds you are doing when you actually need to change them. That and not be compiling dependant jobs while that is going on.

This behaviour also occurred in 5.2. When compiling a job that uses a shared container, the compiler attempts to set a lock on each referenced shared container (Designer already has a lock on the job), so that they are not changed during compilation.

The only solution is a management one; you have to determine times at which compilations using shared containers can be done, and developers have to be sure not to have any shared containers open at those times.

You don't even need to open your shared containers, if you just run the job from the designer (debug), then the sharedcontainer will also be locked by you

br
Tom

chulett wrote:I wouldn't classify this as a 'problem', per se. If you open a Shared Container as if to work on it, it becomes locked just like a job would be. While it is open and locked, jobs that reference it cannot be compiled.

The solution is to only 'access' the shared containers like it sounds you are doing when you actually need to change them. That and not be compiling dependant jobs while that is going on.

Hello Craig,

We are not working on the Shared Container but accesssing it as a copy..
we use the copy of the shared container as a lookup in the job. The shared container is not accessible to any developer for editing. So it is just accessing the shared containers at once.