This job has changed since it was last opened

[eagles_dare13]

I am using Di Studio 4.4 and I get this error on a job from time to time when I open it:

40008 - "This job has changed since it was last opened" message displays when opening a SAS® Data In...

Before installing a fix, I just wish to know what is the cause of this error.

Thank you!

[JBailey]

Hi,

I looked this up in our defect tracking system. This is a random error with an unknown cause.

[Patrick]

This is something which can happen either because someone changed an object outside of your job (eg. some table metadata or a User Transformation). It can also happen because the job metadata is slightly corrupted.

As for corrupted metadata: I've had to deal with this issue as well in the past. It's VERY annoying but it's luckily happening much less with newer DIS versions. I found that what can help is to export the job, then delete it and re-import it. This doesn't work always - but it does work sometimes so may-be worth a try.

[jakarman]

@Jbailey if it is defect with unknown cause, than why is there a fix for documented. 40008 - "This job has changed since it was last opened" message displays when opening a SAS® Data In...

Are you saying that there are fixes being rolling out that are not solving anything? 

[JBailey]

Hi Jaap, I am not saying that at all. I simply saw someone who needed help and tried to help them.

[jakarman]

Yes I understood the good intention.

But seeing that fix description it is 4.21 should be fixed at 4.4 (newer release). Or the fix was missed within version management for DI at SAS or... Never mind the same error-message is popping up. That does not imply it is the same cause.  (correlation is not causation).

As the message still exists with 4.4 it could be an inherited import/conversion problem or a new error. In the latter situation it would the best to have eagels_dare13 it getting registrated with TS in the tracking system. That getting connected with the possible other ones you have found.   
The bad thing is that finding the root cause will cost him a lot of work exactly describing what has happened and when going into failure. 

[Patrick]

I believe "you" won't be able to determine the root cause for this message as it must have happened when writing to SAS Metadata. It will even be very hard to determine where Metadata has been corrupted (so some attributes missing).

If one can export the job from one environment and re-import into another environment and the same issue persists then at least it would be contained within the export file (.spk) and could be analysed by SAS Tech Support.

In my experience what happens in such a case:

- Either the export file doesn't have the issue (and that's where I assume my work-around is successful using "export, delete in metadata, re-import").

- Also the exported data (XML's in a zipped file with extension .spk) is corrupt: Well, one could send it to TechSupport and they can try and figure out what's missing - and may be this will give some indication of what the root cause could have been.

In my experience: It's one of these nasty errors which can happen but it's getting rarer and rarer so best advice would be to upgrade SAS/DIS (last time I looked DIS was at version 4.9 using SAS 9.4).

DIS 4.4 uses SAS 9.3 (I believe DIS 4.6 still uses SAS 9.3 so it might be worth to upgrade the client if this is an issue which occurs too often).

[jakarman]

Patrick I fully agree with you I will not find the root-cause. Also I agree it is very difficult to pinpoint that by SAS TS /development. The export and import is good action to try something on pinpointing.
I also agree on the goal of trying to be at a recent version having most of the available updates.

At this point we are getting apart I think. Is see DI-developers as users of an infrastructural PRODUCTION environment. The have limited time and budget to build a business application using DI.  That is the work they are doing.

Building changing testing of the IT infrastructure (including the SAs installation)  is not their scope.

Change the SAS infrastructure should be part of a infrastructural release management according some policies (change management). Not doing it that way is placing you at the same level as a SOHO excel spreadsheet working line.      

This has as a result that trying infrastructural fixes and changing a sas installation is always having some delay.

For the support of this kind of issues experienced on using sas we also are different (or not?)

I am convinced every problem no matter how difficult should be taken serious by sas.
In my experience when there are some nasty issues that are a/ rare b/ difficult to trace or pinpoint c/ challenging for many interactions. You can easily get bashed by sas as it would be a specific customer issue. Some examples:

- You are the fist nobody has found this problem so it does not exist.

- The last fixes have not been applied... Than finding the last fixes have caused other issues.

- It are the policies (regulations processes)  you have to follow at your company making it complicated.

  If we do it our way ...   (what the hell.. )

That is an attitude to be improved by sas, to be changed in a direction to get it more customer centric.