The other issues you reported are on file and will be addressed when development is able to pick them up.

The development team plans to address the inconsistency of the white package icons in the server section of the Atelier Explorer with Atelier 1.1.

1. You can create a new legacy task (allows you to run COS code) in your application namespace from the System Management Portal: http://docs.intersystems.com/cache20141/csp/docbook/DocBook.UI.Page.cls…

The command to purge all cached queries in the current namespace is "do $SYSTEM.SQL.Purge()". That is described in our class reference here: http://docs.intersystems.com/cache20141/csp/documatic/%25CSP.Documatic…

2. I am checking in with development on which Caché version resolved this bug.

I spoke with development and the fix for this bug will not be in the product until 2017.1 versions and later. (However I also haven't seen this behavior reported outside of 2014.x versions.)

That was true in older versions of InterSystems products, when cached query code was stored in routines rather than classes. A problem could occur if a query executing in one process required round trips from the client to server and a separate process purged cached queries while the client application was still using it. Development resolved this by moving the cached query code into classes - the class definition and OREF are now stored in memory until the client process is done executing the query. This makes purging cached queries safe on a live system in more recent versions.

The change was implemented starting with Caché 2010.2.0 for dynamic SQL and Caché 2012.2 for xDBC queries.

You can use F3 in Eclipse to go to a declaration. This works for many of the use cases for F12 in Studio.

The Atelier development team is actively working towards the 1.1 release. However we do not provide guaranteed timelines for the release of InterSystems products.

I added it as a comment because there is still an unanswered question (why the Server option is disabled in the Replace With menu). So I figured I'd leave the post without an answer until each of your questions has an answer.

I'd suggest filing a new case with Support (email support@intersystems.com or call 617-621-0700). That way an advisor can dial in and help troubleshoot your specific case. Then you or the advisor can come back to this post and give an update on the resolution.

I assume that by the droppins version you mean the standalone Atelier client? Starting with the 1.1.386 release, we dropped support for the standalone Atelier client. There was an announcement in the Developer Community here.

You will need to install Eclipse OXYGEN and add the Atelier plug-in. Detailed instructions can be found in the article linked above, or on the Atelier download site, intersystems.com/atelier.

If you are still having trouble installing the Atelier plug-in, I would suggest opening a WRC case with Support (by emailing support@intersystems.com or calling 617-621-0700) to investigate what is going wrong on your system.

This error can occur for a number of reasons. It could have to do with a firewall, a proxy server, etc. on your system. This is an Eclipse error, outside of InterSystems technologies - your best bet will probably be to Google the error.

John - I'm going to create a WRC case for you and link the associated enhancement requests so that you can see the status as these progress.

Vivek, if Fabian's suggestion is the solution that works for you can you mark that as the correct answer here? Thanks!

You can also see this information in the Atelier Documentation view as you are moving focus within a class. If you do not see this view you can launch it by selecting Window > Show View > Other > Atelier > Atelier Documentation > Open.

For example, I opened Sample.Person on my local Atelier client, selected the tab at the bottom for Atelier Documentation, then clicked on "%Populate" in the list of superclasses. Now I can see this in the Atelier Documentation view:

Thanks for pointing this out, William. I'm going to report it to the Atelier development team to see what we can do.

Thanks for checking in, Wolf. You are correct - the bug is with the recognition of the end of a class query. This can present itself in many ways and cause other parser issues throughout the code.

This has been corrected starting with Atelier 1.2. The fix will therefore be available with the next beta update, which we expect to be coming in February.

Thanks for the additional information. This has been fixed in later server versions but, as John mentioned, those have not been released yet. If you need this fix now we will have to provide it in a patch kit (Adhoc). Note that our Adhocs do not go through our full suit of QD tests . You will need to contact the WRC (support@intersystems.com) to request an Adhoc.

What exactly have you tried so far? What version of Atelier are you using? What version of Caché/Ensemble/HealthShare?

I would suggest contacting the WRC (by emailing support@intersystems.com or calling 617-621-0700) to get further help on this. A Support advisor will be able to give you one-on-one help to get to the root of the problem on your system.

I'm not sure exactly how Eclipse decides where your secure storage file should be located. I thought it had to do with where the application was installed, but after doing a bit more research I think it may be a hard-coded location. I Googled "changing eclipse secure storage location" and found this in the Eclipse documentation:

http://help.eclipse.org/oxygen/index.jsp?topic=%2Forg.eclipse.platform.doc.user%2Freference%2Fref-securestorage-options.htm&cp=0_4_3_3

I think the best next step will be to file a WRC case (by emailing support@intersystems.com or calling +1 617-621-0700). There is some system-specific info that we'd like to collect to try and debug this further.