I am not sure if it is related, but we had similar problems with the same code being compiled at the same time in different namespaces on the same machine.
In the end it turned out to be that all the namespaces were using the same default temp databases for compiling and there was leaking between them. By default each namespace uses cacheTemp database when set up. Sounds similar to what you are describing. The workaround was to create separate temp databases for each namespace and set them as the temp database for each namespace. Cache Configuration Manager Namespace Tab NamespaceName->Default Databases->Temporary Storage Hope this helps Good one to know anyway. This was raised with WRC but no indication of when/if there will be a fix. Jack Stevenson Senior Product Development Manager Mtivity London UK +44 (0)207 801 6211 [EMAIL PROTECTED] "Jeremy Ward" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > 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 > >
