Frequently Asked Questions - AT Usage Questions

This is a known problem with the display cutting off on the right side of Resource records (as of AT 2.0 update 13). You can drag the corner and to enlarge the screen size, but there are a couple of things to check. First, make sure that the screen resolution is at least 1024 x 768 (or higher). Second, shorten any custom RDE screen names to less than 20 characters.

Lastly, if you don’t use the new Scripting plugin for batch searching & replacing box numbers, go the AT program folder, open the plugins directory and delete the ‘ScriptAT.zip’ file. Then restart the AT and you should be able to see the complete Resource record without resizing.

• Login to post comments

If you receive the error message ‘Error connecting to database: database type is not supported’, when attempting to access a saved database connection, you can remedy the problem by editing the Windows registry. To manually remove the AT entry in the system registry, locate the information at:

HKEY_CURRENT_USER\Software\JavaSoft\Prefs\org\archiviststoolkit*

Once it has been deleted, restart the Toolkit and re-enter the connection settings.

If this does not fix the problem, then edit or delete the ‘atdbinfo.txt’ file. To locate the file 'atdbinfo', first, make sure the AT client is closed, then (on Windows machines) the user’s folder; for example, C:\Documents and settings\[username]/atdbinfo.txt. Once you have located the atdbinfo.txt file, you have two options: 1) open it and delete the connection setting that is faulty and any others you want to discard, or 2) simply delete the file (you can add re-save your connection settings again going forward).

With the file either deleted or edited and saved, re-launch the AT, and this should fix the problem.

*To modify the registry:
Click Start
Type REGEDIT
Click OK
The Registry Editor will now open
Locate the key (in this case, 'HKEY_CURRENT_USER') you wish to modify.
Click on the arrow to the left of the key to expand the directory and navigate to HKEY_CURRENT_USER\Software\JavaSoft\Prefs\org\archiviststoolkit
The values contained in the key will now appear in the right pane. Right-click the value you wish to modify or delete.

For MAC users, the problem can be remedied by deleting the file ‘com.apple.java.util.prefs.plist’, located in your Library/Preferences directory (for example, /Users/[your name]/Library/Preferences/com.apple.java.util.prefs.plist).

• Login to post comments

The Archivists’ Toolkit now includes (AT 2.0, update 9 and later), support for an internal database based on HyperSQL 2.0 (HSQLDB). For installation instructions, click on the pdf below.

• If I am using the internal database, can I transfer to it data from another database such as MySQL, MS SQL Server, or Oracle?

No, we currently don’t support the migration of data between any of the database types supported by the AT, including the internal database.

• How much data can I store in the Internal Database?

The amount of data that can be stored is limited only by the available disk space on the user’s computer.

• How do I create a backup of the Internal Database?

First, shut down the AT if it is running. Then search for the “at_db” folder in your “Documents and Settings” folder if you use Windows, or in your home directory if you use Mac OS X or Linux. Once you locate the folder, create a zip archive of it. This is your backup file and it can be restored by simple deleting the "at_db" folder (if one exists), then unzipping it, in the same location. You can also move this backup file to another computer and unzip it in the appropriate folder as a way to share this data.

• How do I re-initialize the Internal Database and start fresh with an empty version?

In the event you need to re-initialize the Internal Database, simply delete the “at_db” folder and run the Maintenance Program to initialize it as before.

• If I upgrade my version of the AT and had an Internal Database setup, do I have to run the Maintenance Program again to initialize the Internal Database again?

No, updating the version of the AT, doesn't require the Internal Database to be initialized again.

• Can I provide access to the Internal Database over a network. For example, I want multiple people to share data like with MySQL, MS SQL Server, or Oracle?

Yes, since the Internal Database is based on HyperSQL, then it can be setup to allow network connections from multiple AT instances. However, we currently provide no technical support for doing this: you will have to consult the HyperSQL User Guide for information on how to accomplish this. Please note, that we advise only users with strong technical backgrounds to attempt this process.

• Login to post comments

On a Macintosh:

1. Right click on the AT application and select show contents
2. In the contents folder open info.plist (this should launch the Property list editor)
3. Open root -> java -> VMOptions
4. Change -Xmx256M to either -Xmx512M or -Xmx1G depending on how much memory you want to allocate

On Windows XP (this should be the same for Vista)

1. Open the Archivists Toolkit lax file in your favorite text editor
2. Find the following line:
   

   lax.nl.java.option.java.heap.size.max=

1. Change the value which is expressed in bytes

   256M = 268435456

   512M = 536870912

   1G = 1073741824

If this does not solve the memory problem, switch to a 64-bit Windows 7 machine using 64-bit JRE (the version that is bundled with the Archivists' Toolkit is 32-bit) which has at least 6GB of memory and change settings to something like:
4GB = 4294967296

• Login to post comments

This type of behavior is common if you are running a Macintosh system using Java 1.6. The next Java for Mac update will hopefully fix the problem. If you are not running a Macintosh please inform the AT team at info@archiviststoolkit.org.

• Login to post comments

Name records in the Archivists’ ToolkitTM are designed to conform with the International Council on Archives’ ISAAR(CPF): International Standard Archival Authority Record for Corporate Bodies, Persons, and Families, 2nd ed. and to support the proposed standard Encoded Archival Context (EAC). Name records also accommodate creation of names according to rules established in standards such as AACR2 and DACS.

The ISAAR (CPF) standard stands behind not only the AT but EAD as well. In compliance with the EAD standard, conferences are considered to be corporate names.

We recognize that choosing the international standard of ISAAR (CPF) over the national standard of AACR/MARC will force some modification of MARC records in which a conference name is encoded as a corporate name. Hopefully, that will be not either a great number of records or a very timely modification.

• Login to post comments

To fix this issue, you need to set at least one return screen value to something other than 0. The directions for this through Navicat are as follows:

1. Find out the tableId of the table in the DatabaseTables table that is causing problems.
2. In the DatabaseFields table use the Filter Wizard to filter for that tableId. It will look something like this tableId is equal to 43
3. Set the return screen order of one of the fields to something other than 0.
4. The database should now work.

Alternativly you can run the following sql command:

UPDATE DatabaseFields,DatabaseTables
SET DatabaseFields.returnScreenOrder = [new return screen order]
where DatabaseFields.fieldName='[field name]' and DatabaseFields.tableId = DatabaseTables.tableId and ->DatabaseTables.tableName='[table name]'

• Login to post comments

The most common reason for this is that one or both of the records you are trying to merge are not valid. This can also occur when you try to merge lookup list terms that are linked to invalid records. Invalid records are missing particular fields that are necessary for proper AT functioning. Currently the only invalid records that can be imported into the Toolkit are Name and Resource records. The import of invalid Names will be prevented in future versions of the AT.

To correct invalid records, open the record and add the information necessary to make it valid. To determine which fields are needed, simply try and save the record by clicking on the "OK" button. You will receive a message listing the fields necessary to produce a valid record.

• Login to post comments

Saving your work frequently helps guarantee that it will indeed be saved. Just like with any other software application, unexpected events can occur- computer crashes, power outages, etc., which can cause a loss of data. If you are using the Toolkit in any type of networked installation, it is especially necessary to save your work often as network connections can timeout or otherwise be interrupted. If you leave your computer for a long time, it is likely that the connection will time out and your data will be lost. Likewise, if your computer goes to sleep and the network connections are cut off, you will lose your data. It is recommended that you save your work often and especially anytime you get pulled away from your desk.

• Login to post comments

This is actually the correct behavior. After the Y2K issue the general consensus is that for years you have to explicitly enter all of the digits for the year you want. In this case if you simply enter "45" you are referring to the year 45 AD. The reason that you can enter more digits is that these are legitimate dates. Granted they are way in the future, but since we do not limit what the fields are used for there could be a reason to enter a year that far in the future. For most dates in the AT we do not allow entry of dates in the future. For the user defined dates this is not enforced again because we do not know what they are going to be used for.

• Login to post comments

Sadly this is a pretty complicated issue. The heart of it is that the ISO 8601 date standard is not implemented in any programming languages or relational database (to my knowledge). Even xml schema does not support all of it. Date ranges specifically are not supported in schema. This is why if you look at the declaration in the ead schema for normalized dates that the date datatype is not used. Since the normalized dates can't be stored or manipulated in anything other that a string field we would have write a bunch of custom programming and datatypes to handle the full range of the ISO standard. This would be a considerable amount of programming and testing to make sure we handled everything correctly. Actually I keep hoping that someone else will do the work in java and publish it as open source. Without that we have decided to only support the granularity of a 4 digit year for the normalized version. This way we can store them as integers and get strict typing without having to write extra code. We can always revisit this in the future but my guess is that it will be hard for it to float to the top of the priority list.

• Login to post comments