Note that this is technically row 8 in the zgetFile entry point of your generated .int code. Caché will generate/update a routine when you compile User.Read.cls, thus the ".1" in the error message.

In many cases, the class code and the generated int code will look the same and it won't matter. But to be sure you can always open the generated code in Atelier by right-clicking the class code in the Editor and selecting View Other Code.

I can't think of any changes between Caché 2016.2 and 2017.2 that would cause that behavior. I'd suggest opening up a WRC case to investigate further (by emailing or calling +1 617-621-0700), since we will likely need more information about your instances.

Francisco is completely correct. As a quick follow-up: Your Atelier Explorer view is a representation of the local copies of source code that you are working with. When you delete something from the Atelier (or Project) Explorer you are deleting that local copy, not the file from source.

If you want to delete from a server you need to use the Server Explorer, or go directly to your instance (or a source control repository if that's where your source code lives).

You can always follow the instructions on the Atelier download page, If you've already got Java 8+ and Eclipse installed, you can skip over to step 2. We're still working on getting the Eclipse Marketplace updated with the 1.2 release**, but you can follow the instructions under "Add one of the Atelier repositories to your Eclipse environment". This gives details about where to enter the repository URL that Michelle noted above.

**Update: The Eclipse Marketplace has been updated with the stable Atelier 1.2 release so you can follow either install/upgrade option listed on the download page.

InterSystems does not provide a whole lot of recommendations on naming conventions in general. Whatever works/makes sense to you is often best. If you'd like to dive into the design aspects of your application, your InterSystems Sales team is going to be a great resource.

There are no plans to implement an equivalent to the Studio SQL Storage GUI in Atelier. The use case for the SQL Storage editor is to maintain legacy applications. The development team's primary focus with Atelier is to support new/more modern development.

If your day-to-day work requires the use of the the Studio SQL Storage GUI, the InterSystems recommendation is that you continue to use Studio.

Thanks for this question, I think it's one that a lot of Atelier users will have. In general we recommend storing each of the different projects that you are working on, or closely related pieces of those projects depending on their size, in their own Caché packages. That helps when you are using source control, as you can pull down just one or a few packages from source to work on in Atelier, rather than having to pull in an entire source code repository.

The main considerations with Atelier will be:

  1. You do not want to have too many files in a given Atelier Project, as this can cause performance problems. (Unfortunately I cannot put a number on this, since it really depends on the size and complexity of those files.) An Atelier Project can be thought of as containing a unit of work - maybe it's the set of files you need to edit to implement a particular new feature.
  2. To help with the potential performance problems I mentioned in #1, working sets will be your friend. This is an Eclipse concept - a working set groups together elements and allows you to restrict the resources that you are viewing. In turn that will limit the background processing done on files/projects not in an active working set. This is discussed in the Eclipse documentation here. There is also some information about that in the Atelier-specific docs here.

We'd love it if you could post more about your experiences, since this is something that effects many users. You can note that in a comment here, or preferably write up a new article and post it on the Developer Community as an example for other users!

Another option would be to disable the OS-specific password provider for your secure storage. That way you will be asked for the master password each time Eclipse starts up.

You can do this from your Eclipse preferences by selecting General > Security > Secure Storage and unchecking the OS-specific option:

If the options laid out in this DC post do not meet your security standards you can feel free to reach out to Support. An advisor will be able to discuss your requirements in more depth and find you a solution that fits your needs.

Atelier is an Eclipse plug-in, and is therefore should be compatible with platforms supported by Eclipse. Eclipse Oxygen's target environments can be found on the Eclipse website here.

To second Fabian, this process can be made easier by making use of Atelier projects.

You can think of an Atelier project as a place to store a unit of work. An Atelier project will typically store all of the files directly related to a particular application, feature, etc. Each Atelier project is configured with a server connection and namespace where code can be compiled and run. You do not necessarily need to create a new project each time you launch Atelier or add something to source control.

There are a number of videos on the InterSystems Learning Services website on this topic (using Atelier with Git/source control). A few that I think will be the most useful:

You may also want to take a look at the Learning Services course catalog. You can filter this by videos related to Atelier. There are a lot of great introductory and more in-depth videos.