Frequently Asked Questions (FAQs) and Known Error Messages, their causes and suggested solutions

MSWord
A faulty Word document was created and attached to a ClassiX object. This Word document must be deleted and replaced with a new Word document.
To avoid the problem in the future, the user's profile must be reset. Check beforehand whether the error only occurs with the local user or whether the domain profile (if available) is affected.

osgi.nl=de_DE

This sets the locale hard to German, which makes the sum calculation correct again.

1. This message occurs when MS Word/Excel has choked.
2. Third-party add-ins have changed the interface of MS Word/Excel so that it is no longer possible to communicate with ClassiX.
3. MS Word/Excel is not responding because the application is currently busy.
4. There is already document open with MS Word/Excel and cannot respond to ClassiX's request or cannot implement ClassiX's request with the document open.
5. In rare cases, a registry entry of MS Word/Excel was made, making it almost impossible to work with MS Word/Excel from ClassiX's point of view.

1. Open Task Manager and end the MS Word/Excel process.
2. Deactivate all third-party add-ins.
3. Wait until MS Word/Excel responds again or end the MS Word/Excel process in the Task Manager.
4. Close document. Check whether a MS Word/Excel process remains open in the Task Manager. End this if necessary.
5. This entry must be removed again. Problem: We do not know which entry it is. Therefore, the Windows profile must be deleted and recreated on the computer.

Afterwards, do not forget to convert the module

The form template cannot be accessed by the user.

or

The template was imported without Word.

Go to the form header and check the path of the template. Can all users reach it? Possibly use the variable CX_ROOTDIR so that the template can be accessed by everyone.

Switch to a computer with Word and open the form header again. Under the menu item "Edit" there is the function "Import XML template". Execute this.

You should then be able to print the form.

ObjectStore Cumulative Patch Release 7.3.0.02

Java is not installed on the computer.

Cause analysis if Java is installed and the message still appears:

• Click OK and open the monitor window in ClassiX (ALT+right mouse button) and execute the following code line:
  "CLASSPATH" SystemObject Call(GetEnvironment) SystemObject Call(Log)
• In the log file (SystemOut folder) of the current ClassiX session, the content of the variable CLASSPATH was written.
• Open the file and copy the path to the clipboard.
  Example: date time 46 * INFO cx.app - Y:\classix\main\Bin\alpha\4.6.0-os2013.0-vc11-32\birt-interface.jar;y:\birt-runtime-osgi-3_7_2\\ReportEngine\lib\*;
• Open a command window and set the CLASSPATH variable to the value from the log file.
  Example: Set CLASSPATH=Y:\classix\main\Bin\alpha\4.6.0-os2013.0-vc11-32\birt-interface.jar;y:\birt-runtime-osgi-3_7_2\\ReportEngine\lib\*;
• Then execute the following line of code in the command window:
  java.exe org.instantview.report.exec.ExecuteReportServer
• The return values should provide information about why the message appears anyway

SAP has its own TAO DLLs and due to ACE's own routine for reloading the DLL during runtime, our DLLs are no longer found as long as SAP is present in the PATH.

Redefine PATH in our startup file so that our DLL, Java and ObjectStore can be found.

Example:

SET PATH=%CX_BIN%;C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\Program Files\Java\jre1.8.0_171\bin;C:\ODI_2013.0\ostore\bin

Recursive macro call may have a maximum of 16 levels. If there are more than one level, this error may occur.

The REP collection contains corrupt pointers.

Call: cxaosr /R CX_CLASS_NAME
Where CX_CLASS_NAME corresponds to the class name whose REP collection is likely to be defective.
The analysis tool then creates a file called "REPAnalyse.lst". One or more lines with "corrupt pointer..." proves that the REP collection is defective.

1. Note down all indices. The indices can probably no longer be deleted via the Index Manager in the Workbench. After repairing, the indices are no longer available. To be able to rebuild them, it must be known which indices exist for the REP collection.
2. Execute in the monitor window:
   BeginTXN CX_CLASS_NAME "cs.className" 0 GetManager(OBJECT) Call(RepairREPCollection)
   CX_CLASS_NAME and "cs.className" must be adjusted accordingly. "cs.className" is the name of the segment in which the REP collection is stored. The segment can be found out with the help of CLASSIX.ODB: The storage location is noted for each class (Class, PseudoClass). This location (Storage) also describes, among other things, the name of the segment that holds the REP collection (CSeg).
3. After the REP collection has been repaired (this may take a few minutes), ^ClassiX® must be restarted.
4. In the Index Manager, the old indices must now be deleted using the RemoveEntry() method. The old, now invalid indices are highlighted in red and are thus easy to find.
5. In the last step, the indices can be rebuilt with the data that was noted in the first step.

The "clusterInfo" slot of the object (here: a job) is negative.

Double-click on the index entry in the Index Manager; "Ordered" should be set under "Sorting".

In this case, the order itself is damaged.

An osverifydb run showed transactions in the order and compound segments whose transaction pointers point to any strings instead of CX_TRANSACTION objects:

The object at <d|classix01:C:\classix\solutions\REMPro\VPro\database\ST17591\VPro_Backup_ST00017591.cxd|2106|0|263ce568|10000> (type "CX_COMPOUND_TXN"), contains a pointer at <d|classix01:C:\classix\solutions\REMPro\VPro\database\ST17591\VPro_Backup_ST00017591.cxd|2106|0|263ce620|10000> (CX_COMPOUND_TXN::CX_TRANSACTION.transaction) incorrectly pointing to an object of mismatched type at <d|classix01:C:\classix\solutions\REMPro\VPro\database\ST17591\VPro_Backup_ST00017591.cxd|566|0|29c16760|10000>; the declared type "CX_TRANSACTION" is incompatible with the type of the target object (char[624]). The type of this object is "1 byte char".

These pointers would all need to be completely zeroed out, as any access to them is likely to cause a crash.
with the osview tool from ObjectStore you could take a look at these strings and maybe you can somehow figure out what went wrong there. The tool can also be used to zero through pointers, although with so many pointers it would probably be better to zero through them automatically (supposedly we have objectTools::SetNullPointerByOSVerfyDBFile for this)

As long as the field "uniqueID" is readable, one should be able to find the order concerned via a simple query. You probably only have to prevent the object from being displayed in the ClassiX shell, as this accesses some data fields and can lead to a crash here.
If the object is so broken that this does not work either, then you can rebuild the REP collection of the orders using CX_DB_UTILITY::RebuildCollection and the corrupt objects are thrown out and logged.
However, only objects that can no longer be recognised as derived from CX_CLASS are recognised as corrupt here. If the uniqueID pointer points to invalid memory, this is not recognised.

Another alternative to find the object would be to export the REP collection of the orders to a file using DumpCollection or ExportCollection (these files consist only of ObjectIds of the elements in text form), then read this file into InstantView and touch the objects individually and log out which object is currently being touched. If the process crashes, you can then see the address of the corrupt object in the log file.

Once you have the object address of the order, you can findthe pointers pointing to it using osverifydb -whohas seg:cluster:offset and then nuke them. This process takes a long time and if possible you should limit the segments to be searched and preferably also the clusters. (Parameters -segement_n, -start_cluster,-end_cluster)

In this case, the object within the transactions slot is damaged.

The error occurs as soon as the object is interacted with, i.e. both a query with the object as a subset and accesses to the object via pointers lead to a crash.

As part of the analysis, a transactions collection containing a broken object was identified. Neither the transactions can be retrieved, nor can I identify this object, because dbUtils Call(GetCollection) and

You can try to remove the corrupt object using :

logCube Get(transactions) TRUE GetManager(OBJECT) Call(GetDBUtility) Call (RebuildCollection)

This logs to the cx.txn logger at ERROR level which objects (with type and object address) were thrown out of the collection.

If this does not work and ClassiX crashes:

Since the object is broken (i.e. deleted or incorrectly typed), osverifydb should recognise this object as an invalid pointer in the collection.

If so, then you get the address of the pointer from the osverifydb log and could zero it with osverifydb (restricted to the segment+cluster) (-illegal_pointer_action null) and then there would only be a NULL pointer in the collection, which you can then easily remove from the collection using RebuildCollection (as above).

GET_VARIABLES = Query missing variables.

MISSING_VARIABLE = error message concerning missing attributes

FindAll(CX_OBJECT_DICTIONARY_CI) iterate(UNSAFE)
{
Copy(uniqueID) SystemObject Call(Log)
}

Skip position to match value and check with working test system:

FindAll(CX_OBJECT_DICTIONARY_CI) iterate(UNSAFE)
{
Index 10 = if { Drop continue }
Copy(uniqueID) SystemObject Call(Log)
}

If the entry does not contain any values or is not used, it can be removed (call in the object inspector):
Name of the root entry point (objectDictionaryCiL0) was determined via the storage entry in the ODB (CX_OBJECT_DICTIONARY_CI -> objectDictionaryCi).

FindAll(CX_OBJECT_DICTIONARY_CI) 10 Swap GetElement
"objectDictionaryCiL0" Swap dbUtil Call(RemoveFromREPCollection)

(2) If the memory requirement is set to "much memory", then the address space handling has been switched off. Set the memory requirement to " little memory" and repeat the operation you want to perform.

1. The ObjectStore server is either not active or cannot be addressed via the network.
   
2. The Windows firewall is blocking the port that the client needs to send feedback to the ObjectStore server.
   
3. The database was set offline during the backup process, thus disconnecting all clients.

1. Enter the command: ping in a command line.
   It returns the IP address of the server. If there is no reply (time-out), the computer on which the database server is running is not accessible in the network:
   Please establish a connection first!
   Enter the command: ossvrping in a DOS box. This can be used to check whether the objectstore database server is active. If it is not active, it must be started.
   To increase the speed of finding the database server, you can edit the file \system32\ drivers\etc\hosts. with a text editor (e.g. NotePad). If there is none, create it (Attention: NO file extension, NotePad uses .txt by default if no extension is given, therefore enter the closing '.' when saving). Insert the following line at the end:

   <ip-adresse> <server-name>

2. The port 51031 TCP must be released in the client firewall settings (firewall exceptions).
   See Firewall Administration for details
   
3. Start new session, contact internal IT department if necessary.

1. Write permissions missing
2. The %TEMP% directory runs over before cxt#######.tmp files.
3. Multiple ClassiX users share a Windows account and when logging off, the %TEMP% directory is deleted.

1. Grant missing write permissions.
2. InstantView code can be stored at status monitors, which is written to a temporary file during execution in order to be able to parse it. If the code cannot be parsed, the file remains. (cxt#######.tmp)
   Find the monitor that contains the wrong code and correct that code. Delete the accumulated cxt#######.tmp files.
3. Either each ClassiX user gets their own Windows account or the script is only allowed to delete the part of the %TEMP% directory that is only used by that one user and not the rest of the folders and data of the other users.

CreateTransObject(CX_ASCII_FILE) -> oFile
oFile Call(ANSICode)

When the TAPI is called, this message is thrown:

This Estos tool can be used to check the TAPI client.

This tool from Ectos can be used to check the TAPI client.