Temporary and Permanent Objects

Objects in DSO Planner databases context could be permanent:

• internal database objects (such as NgcIc, SAC, etc);
• user database objects;

and temporary

• objects existing in one of the observation lists only. Such objects could be created
  • in observation list, using the "Add Object" command;
  • when importing objects into observation list, if imported objects does not contain references to already installed databases (e.g. if the database was removed or a foreign external data file is used).
• It is necessary to emphasize that when objects are added into an observation list from the Object Selection module or View Database module they will be always permanent. The same stands for objects imported into the observation list along with references to existing databases.

Temporary objects creation and maintenance are much easier than that of Permanent objects. They are perfect for adding something quickly to the Chart to see between the stars and calculate local ephemeries, but you don't really care whether they will still exist in the app later or not. Temporary objects are also required for observation lists sharing between users, as they are independent from the particular DSO Planner version or set of installed databases. Also the functionality of Temporary objects in the DSO Planner have some limitations.

Permanent objects could be used in the Object Selection module to filter through, as well as for the Global Search.

Temporary object exists until it is removed from its Observation list, cannot be used in the Global Search, however they are still involved in the Find/Next search.

When importing external list into observation list (from other users) it is temporary objects (with limited functionality) that are created, with the only exception of internal database objects (i.e. when internal database objects from other user list are imported they are created permanent). This is understandable as every user may have its own database structure and its own object location within it. Therefore, other user objects could not be referred to your own databases.

This issue could be partly solved by creating a new user database and importing objects into it. However, before importing you need to create a database with exactly the same additional fields as used in object lists, otherwise information in additional fields will be lost. This may not be a solution when an external observational list that you import contain objects from various user databases.