In custom installation, we can choose which features we want to install and which we don’t depending on our requirement. Whereas in a complete installation, the whole application is installed without any modifications.

No, for the client application to work, it has to be connected to a server, with the exception of Astera ReportMiner Express. ReportMiner Express is a single application that includes an embedded server.

Yes, every license has a specified number of users assigned to it, and the limit depends on the license you have purchased.

The 32-bit Astera is compatible with 32-bit operating system and the 64-bit Astera is compatible with 64-bit operating system.

Astera has a client-server architecture. Astera’s client is a designer studio where flows and job tasks are designed whereas the server is an execution platform for jobs and flows designed on the client. This is why we need to make two installations for Astera – for client and server, separately.

Read more on Astera installation in this document.

In the current implementation, there is no restriction on the number of Astera clients that can be connected to a single server.

When using Astera client for the first time, we need to build a cluster database and set up a repository to communicate with the server and to store information about jobs scheduled and executed on the server. The cluster database the Astera client is currently using is visible in the Server Properties window.

If you want to set up a server cluster for automated load balancing, you can do that by choosing the same cluster database for both Servers. Cluster database for a server can be selected from the Server Properties in the Astera Client application installed on the same machine as the Server.

Astera supports SQL server and PostgreSQL for setting up a cluster database.

Job schedules, job history and all other information associated with jobs running on a server are maintained in the cluster database. The Build Cluster Database option resets the repository if it already exists, erasing all existing data.

To maintain this data while migrating the server to a different machine or a higher version, choose the option to ‘Upgrade Cluster Database’ in Server > Repository Settings instead of building a new database.

In case you are installing the same version on the different machine, this option does not make any changes to the repository, it only associates your existing repository with the new Server. In case of version upgrade, the option adds new tables and columns to your existing repository, making it compatible with the new version, keeping all your previous data intact. In both cases, migration and upgradation, with the Upgrade Cluster Database option, all the jobs scheduled in the existing server will appear in the new Server after the configuration.

As an added step to safeguard your repository data, create a backup of the cluster database before

Visit this link for step-by-step instructions for migrating from Astera 9 to Astera 10.

One of the possible reasons for this could be that the Astera Server does not have access to the directory where you are trying to export your file or import it from.

While working with Astera, you must be connected to the server to execute any jobs. Astera client is only used to design and submit jobs to run on the server. If the server is located on another machine, it needs to have access to your files. This requires you to have a shared folder accessible by both client and server machines.

You can also access files from your local directory if the server is installed on the same machine as the client.