Hi John
I also experienced this problem back in Feb this year and logged a problem with WRC.
The error occurred with CSP autocompile turned on and with multiple namespaces having the same classes and csp pages (i.e. the same application). After using these CSP apps, at random intervals I'd get a CLASS EDITED error for no apparent reason - the only way to clear this was a cache restart.
Intersystems could not help as I could get a reproduceable error.
But then after I wrote an routine (similar to Johns) to upgrade/install classes and csp pages into multiple namespaces, I obtained the same class edited error. This showed itself when running a class method after the compile has finished in at least 2 namespaces. The error was reproduceable...and intersystems reproduced it when I sent my code over.
This was essentially the same problem as the class edited error from the csp page autocompiles.
However after investigation they said it was fixed in 5.1 but not possible to fix in 5.0.x
quote from WRC (in June):
"Hi Jeremy,
I have run this by managment and development. Because this is not a single dev change but a host
of developer changes that change the internal structure of how classes are stored in memory it is not
something that can be reliably ported to Cache 5.0.x."
And then the issue was closed for me...as I left it open...as it was not fixed.
I think it's something to do with the namespace not being stored or checked by the thing that's deciding if a class has been edited - so in the case of the csp issue, the %cspServer routine jumps namespaces and compiles if necessary, then throws the error sometimes.
They supplied me with a workaround for the upgrade/installation class edited issue: this was to job off each individual compile process for each namespace (with output going to text files). So I ended up with 3 jobs for each namespace:
1. class and rule load. class compile.
2. csp page load and compile
3. database updates and conversions
I admit this does work but is not very practical. Especially as I still get this error via the CSP autocompile - even if I have just one or two apps that have autocompile turned on (say for testing/installation) and the other live ones have autocompile turned off, the live ones will sometimes pick up a class edited error. So compiling is now a dangerous thing to do!
And obviously it still means that in development/test environments the class edited error occurs quite a lot as autocompile is turned on.
I did come up with a possible workaround for the CSP class edited error - but I can't use it: specify different package names for each CSP application so that the generated classes are all differently named across namespaces.
John if it helps my WRC ref is 594161
Regards
Jeremy Pronoia
kevin furze wrote:
Peter
oh and where is the .err parameter in do $System.CSP.LoadPageDir(dir,flags,.ERR)
cannot even go and make a coffee - reports a non-existent error but
it's scrolled off the screen buffer so am not sure if the error is
real or not !
try using the logging options <ALT-L> and have all the compile responses go to a log, then just open the log and scan down it, ignore the buffer . . .
now you can enjoy your coffe ;-}
kev
