Troubleshooting

JDataStore is a feature of JBuilder Professional and Enterprise, and the Inprise Application Server.

Here are some tips for when problems occur.


Debugging JDataStore applications

Set the saveMode property to 2 when debugging a non-transactional JDataStore. The debugger stops all threads when you are single-stepping through code or when breakpoints are hit. If the saveMode property isn't set to 2, this keeps the JDataStore daemon thread from saving modified cache data. For more information, see "Controlling how often cache blocks are written to disk."


Verifying JDataStore contents

If you suspect that cache contents were not properly saved on a non-transactional JDataStore, you can verify the integrity of the file with the JDataStore Explorer. See "Verifying the JDataStore" for more information.

There is also a borland.datastore.StreamVerifier class with public static verify() methods that can verify a single stream or all streams in JDataStore. For more information, see the DataExpress Component Library Reference.

Note that transactional JDataStores have automatic crash recovery when they open. You never need to verify them.

If problems are encountered, use the JDataStore Explorer (see "Copying JDataStore streams") or the DataStoreConnection.copyStreams() method to repair the damage.

Problems locating and ordering data

Sun Microsystems makes changes to its java.text.CollationKey classes from time to time as it corrects problems. The secondary indexes for tables stored inside a JDataStore use these CollationKey classes to generate sortable sort keys if a non-US locale is being used. When Sun changes the format of these CollationKeys, the secondary indexes created by an older Sun JDK may not work properly with a new Sun JDK. The problems resulting from such a situation manifest themselves in the following ways:

Currently, the only way to correct this is to drop the secondary indexes and rebuild them with the current JDK. The StorageDataSet.restructure method also drops all the secondary indexes.

Saving log file

As old log files are no longer needed for active transactions or crash recovery, they are automatically deleted. Old log files can be saved by listening to the DataStore.response event for a ResponseEvent.DROP_LOG notification. At that point, you can copy the log file to another location before it is deleted, or you can cancel() the event to prevent the deletion of the log file.