SYMPTOMS
When sending an email to users for automatic notification, or manually by selecting email actions from the ILLiad client menus, when the email window opens a SQL error occurs producing the following message: SQL ERROR: Unmatched " near transaction #
The resulting email is missing the patron data, or parts of it, and the email cannot be sent.
ERROR MESSAGES
SQL ERROR: Unmatched " near transactionnumber
CAUSE
When patrons register for ILLiad for the first time, they must choose a delivery location from a drop down menu. If this drop-down is changed to include an invalid Delivery Location, or if it is removed entirely, then the user record is missing this required value.
RESOLUTION
To correct this problem, users should verify that their users have a "delivery location" from within the client:
1. From the ILLiad Client main menu, select Edit | Customer
2. Search for and double-click the patron you wish to verify
3. On the right hand side of the User Lookup and Edit form, check the delivery location field.
Sites should contact UNS (OCLC licensees) or Atlas (Original licensees) if this problem occurs, so that the issue can be corrected at its root, the web pages, and so the existing data can be updated correctly. Users without SQL experience should contact Atlas or UNS to assist them with this, if they are unable to do so themselves or the system admin is not available.
MORE INFORMATION
A list of valid delivery locations is available in knowledge base article 36448.
SUMMARY
The most crucial component of the ILLiad system is the SQL database. Most other components can be replaced, but the SQL Server database contains all of the request history, users, tracking and customization settings for the ILLiad system. It is imperative to have regular and safe backup copies of the ILLData database.
MAKING A SINGLE BACKUP OF ILLDATA
You should see a "Backup in Process" message followed by a "Backup Operation has Completed Successfully" message. Once the second message is displayed, the database has been backed up. The file that was created (i.e. c:\illiad\backup\ILLData20030101.bak) is a copy of the entire ILLData database that could be used to restore on another machine. This file should be backed up to another external media such as a tape drive etc.
SCHEDULING REGULAR BACKUPS OF ILLDATA
To schedule regular backups of the ILLData database, you can follow the same directions as above only check the schedule option at the bottom of the screen and choose the ... button at the right to change it.
Once on the Edit Schedule form, give your schedule a name (Daily at 10pm, for example). Leave the Recurring radio button chosen and click the Change button at the right to edit it. You can setup whatever schedule you want, but ideally you should have one job that appends to the file and another job that overwrites that file once a week. For example, you can have the first job run daily at 10pm and append to the file (changing it to append with the radio button on the SQL Server Backup form). Then make a second job that writes to the same file and overwrites it once a week, say Wednesday at 6am. This would provide a backup file that had several database copies in it from each night (to allow you to catch a change that happened several days ago) and then overwrite it once a week to prevent the file from growing too large.
You can schedule your backup to overwrite each night as long as you are then copying that backup file to another location that would have a week's supply of backups. So if you backed that file up to tape each night after the SQL backup job ran, you would not need to append to the SQL job (using overwrite options) within SQL Server.
VIEWING/MANAGING BACKUP SCHEDULES
To view any scheduled backups you may have in SQL Server Enterprise Manager, go to Microsoft SQL Servers - SQL Server Group -YourServerName - Management - SQL Server Agent - Jobs. Any backup jobs you have will be listed under Jobs. Double-click on a job to see its properties. You can change the schedule for that job or add notifications for success and/or failures. The SQL backup job itself is a SQL script stored in Step 1 of the Steps. An example of the script is:
BACKUP DATABASE [ILLData] TO DISK = N'c:\illiad\backup\ILLDataBackup.bak' WITH INIT , NOUNLOAD , NAME = N'ILLData Backup to Hard Drive - Overwrite', NOSKIP , STATS = 10, NOFORMAT
The job above is backing up to c:\illiad\backup\ILLDataBackup.bak and overwriting that file (WITH INIT). The name of the job in SQL is "ILLData Backup to Hard Drive - Overwrite." The only difference you may see for the other jobs would be the tag for appending (WITH NOINIT) instead of overwriting (WITH INIT).
As a note, be sure that your SQL Server Agent is running or none of the scheduled backup jobs will execute. You can check that service under Services in the Control Panel .. Administrative Tools. Be sure that SQLServerAgent is set to Automatic startup and is currently running.
SUMMARY
In some cases, libraries may want to break the link in ILLiad between the user and their requests. This document explains a possible way to do this, as well as explains the consequences in ILLiad.
LIMITATIONS
If you break the username link in ILLiad, you will not be able to do the following items:
BREAKING THE LINK BETWEEN USERS AND TRANSACTIONS
To break the link in ILLiad, basically you'll replace all instances of a username with a new, "standard" username. If you want to retain the status of the person, you can make several standard usernames (like "Faculty", "Staff", "Undergraduate", etc) or you can just make a single username to change the username to (like "BrokenUsername"). Create the username using the ILLiad web pages or through the SQL Enterprise Manager.
Once you've created the usernames, you need to change several items in the database:
In order to do this, you'll have to decide which transactions you want to break the link on. Once you've decided on the selection criteria, you'll take the list of TransactionNumbers and, using a SQL script or an Access link, you'll make the changes needed from the list above.
Breaking the link in this fashion will remove all ties in ILLiad between the user requesting the item and the item itself. But since the item remains in ILLiad, the Copyright tracking functionality will continue to work.
EXAMPLE
If you wanted to be able to break the links on all requests as soon as they were finished by changing the Username to "BrokenUsername", you could write a SQL Script to run once a day that would do this for you on the SQL Server. Here is an example:
Use ILLData
Go
Declare @TN int
Select @TN = (select Max(TransactionNumber) from Transactions where TransactionStatus = 'Request Finished' and Username <> 'BrokenUsername')
While (@TN > 0)
Begin
Update Transactions set Username = 'BrokenUsername', InternalAcctNo = '' where TransactionNumber = @TN
Update Tracking set ChangedBy = 'BrokenUsername' where TransactionNumber = @TN
Update Notes set AddedBy = 'BrokenUsername' where TransactionNumber = @TN
Delete from EMailCopies where TransactionNumber = @TN
Select @TN = (select Max(TransactionNumber) from Transactions where TransactionStatus = 'Request Finished' and Username <> 'BrokenUsername')
End
This script could be modified to allow, for example, only deleting items that are at Request Finished and are a certain length of time old, or only doing this for people who request it (or who request for it not to happen).
SUMMARY
You can change the port that ILLiad uses to connect to Microsoft SQL Server (to get around an arbitrary firewall blockage for example). This involves making a change on each server machine (if you have more than one component to the ILLiad server) and each client machine. This also involves editing a configuration file for OpenURL.
Making this change will disrupt ILLiad service until all components are changed.
HOW TO CHANGE THE MICROSOFT SQL SERVER 2000 PORT ON THE SERVER
HOW TO CHANGE THE MICROSOFT SQL SERVER 2000 PORT ON THE CLIENT
HOW TO CHANGE THE MICROSOFT SQL SERVER 2000 PORT FOR OPENURL
SUMMARY
Using the SQL Enterprise Manager tool in Microsoft SQL Server, you can increase the size of data fields in ILLiad up to 250 characters.
EXAMPLE
One field that many sites need to expand is the SSN field. Many sites use a longer number than a 9 digit ssn, so need to increase the size. This example shows how to increase the SSN size from 9 to 14.
MORE INFORMATION
You can not increase the field size to more than 250 characters. Also, be aware that increasing file sizes may change the default print documents appearances (since the data fields are now larger than the defaults).
SUMMARY
Following the instructions below will enable logging in the ILLiad Gateway.
Caution: Gateway Logging should only be enabled to aid in the diagnosis of a problem - the log files tend to get large quickly.
ENABLING LOGGING
To enable logging in the ILLiad Gateway, create a file called c:\illiad\gateway\log4d.props on the web server that contains the following:
#---- begin log4d.props ----
log4d.debug=TRUE
log4d.categoryFactory=TLogDefaultCategoryFactory
# root priority - valid values are 'DEBUG', 'INFO', 'WARN', 'ERROR', 'FATAL'
log4d.rootCategory=DEBUG,ROOT
# root appender
log4d.appender.ROOT=TLogFileAppender
log4d.appender.ROOT.append=TRUE
log4d.appender.ROOT.fileName=c:\illiad\gateway\gateway.log
log4d.appender.ROOT.errorHandler=TLogOnlyOnceErrorHandler
log4d.appender.ROOT.layout=TLogPatternLayout
log4d.appender.ROOT.layout.dateFormat=yyyy-mm-dd hh:MM:ss,zzz
log4d.appender.ROOT.layout.pattern=%d [%p] %c %t - %m%n
#---- end log4d.props ----
The ILLiad Gateway will now log to a file called c:\illiad\gateway\gateway.log
Note: That file may not allow you to open it while the gateway is still running. You may need to stop and restart the ILLiad Gateway service to open the file.
DISABLING LOGGING
To disable logging in the ILLiad Gateway, rename the c:\illiad\gateway\log4d.props file to something else (i.e. disable-log4d.props). If the gateway can not find that file, it will not log any actions.
SUMMARY
Following the instructions below will enable logging in the ILLiad Web DLL.
Caution: DLL Logging should only be enabled to aid in the diagnosis of a problem - the log files tend to get large quickly.
ENABLING LOGGING
To enable logging in the ILLiad DLL, create a file called c:\illiad\dll\log4d.props on the web server (the server where the ILLiad.dll file is located) that contains the following:
#---- begin log4d.props ----
log4d.debug=TRUE
log4d.categoryFactory=TLogDefaultCategoryFactory
# root priority - valid values are 'DEBUG', 'INFO', 'WARN', 'ERROR', 'FATAL'
log4d.rootCategory=DEBUG,ROOT
# root appender
log4d.appender.ROOT=TLogFileAppender
log4d.appender.ROOT.append=TRUE
log4d.appender.ROOT.fileName=c:\illiad\dll\ILLiadDLL.log
log4d.appender.ROOT.errorHandler=TLogOnlyOnceErrorHandler
log4d.appender.ROOT.layout=TLogPatternLayout
log4d.appender.ROOT.layout.dateFormat=yyyy-mm-dd hh:MM:ss,zzz
log4d.appender.ROOT.layout.pattern=%d [%p] %c %t - %m%n
#---- end log4d.props ----
The DLL will now log to a file called c:\illiad\dll\ILLiadDLL.log
You may need to change the permissions on the c:\illiad\dll directory to allow the Internet Guest Account (IUSR_ILLIAD or similar) to create and write to a file. Also that file may not allow you to open it while the dll is still running. You may need to stop and restart the web server to open the file.
DISABLING LOGGING
To disable logging in the ILLiad DLL, rename the c:\illiad\dll\log4d.props file to something else (i.e. disable-log4d.props). If the DLL can not find that file, it will not log any actions.
SUMMARY
If you are interested in utilizing SSL encryption, we would suggest that you test all of your links and web pages before you make the change. We have outlined some common "issues" you may encounter below.
Once the certificate is installed, to utilize the SSL web pages, you simply have to change your links to the ILLiad web server to be https: For Example: https://Servername/illiad/logon.html.
You will need to do this for every link that you have pointed to the ILLiad server, i.e. on your library home page, ILL homepage, or other sites. This will mean that all data sent between your users and the web server will be encrypted.
You do not have to move your web pages or make any changes to them. See "Issues You May Encounter" below for any exceptions to this.
ISSUES YOU MAY ENCOUNTER
SUMMARY
Before going live with ILLiad, you may want to remove the addresses supplied by default and use addresses from another database or electronic format. This can be done by formatting the addresses in an Excel file and then importing it into the LenderAddresses(ALL) table within the ILLData database. If you are a hosted site, you will format the Excel file but then send that file to Atlas Systems for it to be imported into your database.
Remember that you only want to do this step before going live with ILLiad so that you do not remove any addresses already used during processing. If you run this query after going live, you will lose the link between lending requests and the library who requested them as well as borrowing requests and the supplying library. This will disrupt processing as well as statistics for all those requests.
Note that in a shared server installation, your LenderAddresses table will be named LenderAddressesALL. Inside that table is a set of addresses for each site code (NVTGC). You will need to remove the entries for each site code you wish and then add new entries for each site code using these instructions. The term LenderAddresses in this article is synonymous with LenderAddressesALL for a shared server installation.
FORMATTING THE ADDRESSES TO IMPORT
The Excel file must have the appropriate fields in it to import into LenderAddresses. Descriptions of each field and its use are in the Reference Guide, but below is a list of all fields in LenderAddresses with any notes about the appropriate value. Fields that are required are starred (*) and those that are strongly recommended are in bold.
| Field | Field Length in chacters | Notes |
| LenderString * | 16 | The symbol for that library. It should be the OCLC or Docline symbol if you receive requests from them over those systems. |
| AddressNumber * | [number] | This should typically be a value of 1. If you have multiple addresses for an OCLC symbol, you can add them in with the same LenderString but an AddressNumber of 2, 3, etc. |
| NVTGC * | 20 | If you are shared server, this should be your site code. If you are single server, this should be Lending. If your table is named LenderAddressesALL, this field is used to separate each view of LenderAddresses for the shared server site codes. |
| LibraryName | 40 | The name of the library |
| Address1 | 80 | The first line of the library address (not library name - generally the institution name) |
| Address2 | 80 | The second line of the library address |
| Address3 | 80 | The third line of the library address |
| Address4 | 80 | The forth line of the library address |
| BAddress1 | 80 | The first line of the billing address (optional if different than shipping address above) |
| BAddress2 | 80 | The second line of the billing address (optional) |
| BAddress3 | 80 | The third line of the billing address (optional) |
| BAddress4 | 80 | The forth line of the billing address (optional) |
| Fax | 15 | The library fax number |
| ArielAddress | 50 | The library Ariel address |
| Phone | 15 | The library phone number |
| PriorityShipping | 3 | This field should be skipped. |
| CopyrightPayer | 3 | Only give a value of "Yes" (case-sensitive) if this library includes copyright fees in their charges. Otherwise, the value can be blank or "No". This only pertains to borrowing requests where you would not want to pay additional copyright on items received from this symbol. |
| BillingExempt | 3 | This field should be skipped. |
| BillingCategory | 50 | Enter the value you wish to assign the library based off of your billing setup. If you do not bill for lending, you can skip this field and leave it blank. |
| LibCopyCharge | 50 | This field is only used for reference so you can store any additional information here. |
| LibLoanCharge | 50 | This field is only used for reference so you can store any additional information here. |
| LibBillingMethod | 50 | This field is only used for reference so you can store any additional information here. |
| Notes | 250 | This field is only used for reference so you can store any additional information here. |
| EFTS | 3 | Values of "Yes" or "No" (case-sensitive). Only set to Yes if that library is a Docline institution that you wish to charge via EFTS. |
| EMailAddress | 50 | The library email address |
| OdysseyIP | 50 | This field should be skipped. It will be auto-populated by ILLiad once you receive article requests from other Odyssey users. |
| OverrideIFM | 3 | This field should be skipped. It is *very* rarely used and only for libraries who send you requests with IFM information but that you wish to bill by an invoice. |
| ISO | 3 | Only fill out this field with a "Yes" value if you have all the ISO ILL information for this library and plan on using ISO ILL. |
| ISOIPAddress | 50 | The ip address of that library if they are using ISO ILL. Otherwise leave blank. |
| ISORequesterId | 50 | The requester id of that library if they are using ISO ILL. Otherwise leave blank. |
| ISOUsername | 50 | This field should be skipped. |
| ISOPassword | 50 | This field should be skipped. |
| WebPassword | 100 | This field should be skipped. You can reset the web password from within the client for any libraries you wish to give access to your Lending web pages. |
| Blocked | 3 | This field should be skipped. |
| TrustedSender | 3 | This field should be skipped. |
| ISOPaymentMethod | 6 | This field should be skipped. |
| DefaultShippingMethod | 50 | This field should be skipped. |
You can download a sample Excel file (zipped format) to start with and verify your formatting.
Some helpful hints in adding addresses to your Excel file are below.
SUMMARY
Because it is not always desirable to implement a newly installed ILLiad system on January 1, it is possible to import year-to-date Copyright information into your ILLiad database for reporting purposes. This will allow the Copyright List to display in the Copyright form of the ILLiad client for these imported titles once five or more of them have been requested. As the fee information being imported is not accurate, some adjustment to the data will need to be made for Copyright Clearance Center reporting.
To do this, create an Excel spreadsheet containing the information to be imported. This information may be pulled from whatever automated system you are currently using.
This Excel file should contain one entry in the file for each article request that has been successfully filled during the current calendar year. The following fields MUST exist in the Excel file for this process to work properly:
| Field Name | Value |
|---|---|
| TransactionNumber | The TransactionNumber value of the first transaction in the file to be imported should be set to "1" initially. All subsequent TransactionNumber values should increment by one. This is best done using a formula in Excel. Just before importing, the initial TransactionNumber value will be changed to a number one greater than the largest ILLiad TransactionNumber in the table. |
| Username | The username should be set to a generic value, such as "Copyright". This will help to identify these transactions as having been imported for the purpose of Copyright reporting. This username will need to exist as a legitimate user of the system before these transactions will display properly in the ILLiad client. If you are using a shared server ILLiad system, the username should be something like "CopyrightABC", where ABC is the NVTGC code of the appropriate site. This way each site can have its own easily identifiable set of imported Copyright requests. |
| RequestType | The RequestType value should be set to "Article" for all transactions in the Excel file. |
| PhotoJournalTitle | This value will vary for each entry in the Excel file. |
| PhotoJournalYear | This value will vary for each entry in the Excel file. |
| TransactionStatus | The TransactionStatus value should be set to "Imported from Legacy System" for all transactions in the Excel file. |
| ISSN | This value will vary for each entry in the Excel file. |
| BaseFee | The BaseFee value should be set to "1" for all transactions in the Excel file. |
| Pages | The Pages value should be set to "1" for all transactions in the Excel file. |
| ProcessType | The ProcessType value should be set to "Borrowing" for all transactions in the Excel file. |
| DocumentType | The DocumentType value should be set to "Article" for all transactions in the Excel file. |
| CopyrightAlreadyPaid | The CopyrightAlreadyPaid value should be set to "No" for all transactions in the Excel file. |
Things to Remember:
Before Importing The Copyright File:
For hosted ILLiad systems, send the Copyright file to be imported to Atlas Systems for importing.
For self-hosted ILLiad systems, once the Copyright file exists in the appropriate format, perform the following actions:
Select Max(TransactionNumber)
from Transactions
Importing The Copyright File:
SUMMARY
By default, the username field for ILLiad customers is 20 characters. In some cases this field may need to be expanded to a larger size to accomodate usernames longer than 20 characters. An example would be a site using the customer's full name or full email address as their username (i.e. johnqpublic@university.edu). Also if you are importing Loansome Doc requests in version 2.5 of Docline, the Loansome Doc UserID has been replaced with the Patron EMail as a matching point against the ILLiad username, which may also require expanding the username field.
HOWTO
There are several tables in the ILLData database that need to be edited. Be sure to backup the SQL Server database before making any of these changes. The tables and field names that need to be edited are:
| Table Name | Field Name |
| History | Username |
| ImportValidation | Username |
| InvoiceSessions | CustomerSymbol |
| TestModeInvoiceSessions | CustomerSymbol |
| Tracking | ChangedBy |
| Transactions | Username |
| UserAccountsLink | Username |
| UserNotes | Username |
| Users or UsersALL | Username |
| WebSession | Username |
SHARED SERVER DATABASES
If you are a shared server installation and expand the username field in the UsersALL table, you will need to drop and recreate the User views for each site. This can be done with one SQL query. Open the SQL Query Analyzer and login to the SQL Server as a system administrator (sa account or Windows authentication). In the blank white query window paste the following query:
----------------
DECLARE nvtgc_cursor CURSOR
FOR
SELECT TABLE_SCHEMA
FROM INFORMATION_SCHEMA.VIEWS where TABLE_NAME = 'Users' ORDER BY TABLE_SCHEMA
OPEN nvtgc_cursor
DECLARE @ViewNVTGC varchar(10)
SET @ViewNVTGC = '00000000'
FETCH NEXT FROM nvtgc_cursor INTO @ViewNVTGC
WHILE (@@FETCH_STATUS <> -1)
BEGIN
IF (@@FETCH_STATUS <> -2)
BEGIN
SELECT @ViewNVTGC = RTRIM(@ViewNVTGC)
DECLARE @VIEWDEF varchar(255)
SET @VIEWDEF = (SELECT VIEW_DEFINITION from INFORMATION_SCHEMA.VIEWS where TABLE_NAME = 'Users' and table_schema = @ViewNVTGC)
EXEC ('drop view ['+ @ViewNVTGC +'].Users')
EXEC (@VIEWDEF)
EXEC ('grant select on ['+ @ViewNVTGC +'].Users to [illiad]')
END
FETCH NEXT FROM nvtgc_cursor INTO @ViewNVTGC
END
CLOSE nvtgc_cursor
DEALLOCATE nvtgc_cursor
----------------
Run the above script by clicking the green arrow at the top of the form or hitting F5. After the query has been run, close the SQL Query Analyzer. You do not need to save changes to the query.
Initial Steps:
Once the new ILLiad Server is installed and tested (making sure the web pages and client seem to be functional), the following may be done in any order. These are not particularly time sensitive and can really be done at any point prior to the data migration:
1)Copy over your current set of ILLiad web pages(overwriting the existing default files) from the old Server. The default location for these is c:\inetpub\wwwroot\illiad but they may actually be installed anywhere. This will preserve any web page customization that you have done. Once copied over, test the web pages to make sure they work in the new location.
2)Copy over any customized Print Templates (Word Docs) and Email Templates to the new Server. These are typically found in the ILLiad Share under Print and Email respectively.
3)Copy over your Connector Batch Files and Scheduled Tasks to the new server. The batch files are typically found in the c:\illiad\Connector folder. The Connector Scheduled Tasks (if you are using Scheduled Tasks rather then SQL Agent for scheduling the jobs) can be found in C:\WINDOWS\Tasks or C:\WINNT\Tasks.
Note: In order for the scheduled tasks to copy to the new server correctly, you must copy them to a temporary location first, move the temporary folder to the new server, and then copy them into the Scheduled Tasks location on the new server. If you try to copy them directly to the new server's Scheduled Tasks location, it will not work properly.
When you are Ready to Migrate the Data:
Once you have a working server with all of your customized web pages and print/email templates, you are ready for the data migration.
The following steps ARE time sensitive. Up until this point, the existing system was still up and running and usable by customers and staff alike. This can be done at any point, but be aware that your ILLiad system will be unusable for the duration of this process.
4)Disable the web pages for the old ILLiad Server.Stopping the web pages in IIS should be sufficient. If you are using OpenURL, you'll want to disable that as well. Stopping the OpenURL service on the old server should do this. This just prevents any new requests from coming into the system.
5)Get everyone out of the system. Inform all ILL staff (and anyone else who might access the system) that they will need to close the ILLiad client, Customization Manager, and User Manager (and anything else ILLiad related) until further notice. This should prevent any changes to the data during the migration process.
6)Back up the database. Once you are sure that everyone is out of the system, back up the ILLData database on the old server using SQL Enterprise Manager. (This is just a precaution, but is always a good idea.)
7)Copy over the logons from the old ILLiad Server.There are several steps to this process:
" Run the following script on the Old ILLiad Server to copy the existing Logins from the Old Server.
----- Begin Script, Create sp_help_revlogin procedure -----
USE master
GO
IF OBJECT_ID ('sp_hexadecimal') IS NOT NULL
DROP PROCEDURE sp_hexadecimal
GO
CREATE PROCEDURE sp_hexadecimal
@binvalue varbinary(256),
@hexvalue varchar(256) OUTPUT
AS
DECLARE @charvalue varchar(256)
DECLARE @i int
DECLARE @length int
DECLARE @hexstring char(16)
SELECT @charvalue='0x'
SELECT @i=1
SELECT @length=DATALENGTH (@binvalue)
SELECT @hexstring='0123456789ABCDEF'
WHILE (@i <= @length)
BEGIN
DECLARE @tempint int
DECLARE @firstint int
DECLARE @secondint int
SELECT @tempint=CONVERT(int, SUBSTRING(@binvalue,@i,1))
SELECT @firstint=FLOOR(@tempint/16)
SELECT @secondint=@tempint - (@firstint*16)
SELECT @charvalue=@charvalue +
SUBSTRING(@hexstring, @firstint+1, 1) +
SUBSTRING(@hexstring, @secondint+1, 1)
SELECT @i=@i + 1
END
SELECT @hexvalue=@charvalue
GOIF OBJECT_ID ('sp_help_revlogin') IS NOT NULL
DROP PROCEDURE sp_help_revlogin
GO
CREATE PROCEDURE sp_help_revlogin @login_name sysname=NULL AS
DECLARE @name sysname
DECLARE @xstatus int
DECLARE @binpwd varbinary (256)
DECLARE @txtpwd sysname
DECLARE @tmpstr varchar (256)
DECLARE @SID_varbinary varbinary(85)
DECLARE @SID_string varchar(256)IF (@login_name IS NULL)
DECLARE login_curs CURSOR FOR
SELECT sid, name, xstatus, password FROM master..sysxlogins
WHERE srvid IS NULL AND name <> 'sa'
ELSE
DECLARE login_curs CURSOR FOR
SELECT sid, name, xstatus, password FROM master..sysxlogins
WHERE srvid IS NULL AND name=@login_name
OPEN login_curs
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd
IF (@@fetch_status=-1)
BEGIN
PRINT 'No login(s) found.'
CLOSE login_curs
DEALLOCATE login_curs
RETURN -1
END
SET @tmpstr='/* sp_help_revlogin script '
PRINT @tmpstr
SET @tmpstr='** Generated '
+ CONVERT (varchar, GETDATE()) + ' on ' + @@SERVERNAME + ' */'
PRINT @tmpstr
PRINT ''
PRINT 'DECLARE @pwd sysname'
WHILE (@@fetch_status <> -1)
BEGIN
IF (@@fetch_status <> -2)
BEGIN
PRINT ''
SET @tmpstr='-- Login: ' + @name
PRINT @tmpstr
IF (@xstatus & 4)=4
BEGIN -- NT authenticated account/group
IF (@xstatus & 1)=1
BEGIN -- NT login is denied access
SET @tmpstr='EXEC master..sp_denylogin ''' + @name + ''''
PRINT @tmpstr
END
ELSE BEGIN -- NT login has access
SET @tmpstr='EXEC master..sp_grantlogin ''' + @name + ''''
PRINT @tmpstr
END
END
ELSE BEGIN -- SQL Server authentication
IF (@binpwd IS NOT NULL)
BEGIN -- Non-null password
EXEC sp_hexadecimal @binpwd, @txtpwd OUT
IF (@xstatus & 2048)=2048
SET @tmpstr='SET @pwd=CONVERT (varchar(256), ' + @txtpwd + ')'
ELSE
SET @tmpstr='SET @pwd=CONVERT (varbinary(256), ' + @txtpwd + ')'
PRINT @tmpstr
EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
SET @tmpstr='EXEC master..sp_addlogin ''' + @name
+ ''', @pwd, @sid=' + @SID_string + ', @encryptopt='
END
ELSE BEGIN
-- Null password
EXEC sp_hexadecimal @SID_varbinary,@SID_string OUT
SET @tmpstr='EXEC master..sp_addlogin ''' + @name
+ ''', NULL, @sid=' + @SID_string + ', @encryptopt='
END
IF (@xstatus & 2048)=2048
-- login upgraded from 6.5
SET @tmpstr=@tmpstr + '''skip_encryption_old'''
ELSE
SET @tmpstr=@tmpstr + '''skip_encryption'''
PRINT @tmpstr
END
END
FETCH NEXT FROM login_curs INTO @SID_varbinary, @name, @xstatus, @binpwd
END
CLOSE login_curs
DEALLOCATE login_curs
RETURN 0
GO
----- End Script -----
This will create a Stored Procedure called sp_help_revlogin, which can be found on the Old Server in the SQL Query Analyzer under the Master database, under Stored Procedures.
- Run the following Query: EXEC master..sp_help_revlogin
- This will run a query based on the stored procedure and give you the results of that query. These results will be in the form of another (third) query that is to be run on the New ILLiad Server.
- Copy the resulting Query to the New ILLiad server and paste it into the Query Analyzer. (You can save it as a text file and move it that way if this makes it easier.)
- Then just run that query. This will create the same set of logons that existed on the Old Server with the same passwords.
(FYI - More information on this step of the process can be found at: HOWTO: Updating Across a Multiple Server ILLiad Installation
SUMMARY
Often ILLiad will be installed across multiple servers. Such an installation requires a SQL Server, a Web Server, and a Share Server. Note that these may be installed across two server machines, usually a SQL Server and a Web/Share server, or across three servers, each with it's own component.
To update the ILLiad server(s) to a new released version, perform the following steps:
All of the directories should point to the local machine except for the ILLiad Backup Directory. That folder should be the local path from the perspective of the SQL Server. For example if you are backing up your database to the E drive on the SQL Server, the ILLiad Backup Directory should be e:\illiad\backup\ regardless of the E drive on the Web/Share server. You would not want to map a drive to the SQL server from the Web/Share server for that folder, because the backup script runs on the SQL Server and executes from its perspective.
SUMMARY
The newest version of McAfee VirusScan (8.0) includes a firewall feature intended to block mass-mailing email worms. This feature will also block email sent by the ILLiad client (with this particular error message - E-Mail Not Sent! Error 10053), unless you add the ILLiadClient.exe executable to an exceptions list in the program for each client machine.
Other antivirus programs may have similar exception needs.
SUMMARY
For a fairly advanced description of the ILLiad NVTGC field and the various possible uses of it, click this link.
Important: This document is intended for informational purposes only. The successful implementation of Shared Server Support requires a licensing change in addition to several system changes not discussed in this NVTGC-specific document. Please contact OCLC if you which to implement Shared Server Support.
SUMMARY
All customers statuses in ILLiad are limited in the number of active requests allowed in the ILLiad system at any given time. By default all statuses have the same limit and that number is set by the RequestLimit key in the Customization Manager (under Web Interface .. Limits). All other limits keys are then ignored.
There is an option to give separate request limits to each status. In this case, the key for UserRequestLimit is set to Yes and a key must exist for each customer status in the database. The defaults are already provided, but if additional statuses have been added, RequestLimit keys need to be created for those as well (i.e. RequestLimitDoctoral, RequestLimitAdministrative, etc.). Each key can then have its own number value for the number of active requests allowed for that status. If the UserRequestLimit is changed to Yes, but all limit keys do not exist, the dll may return an error when attempted to request an item of "Key Value Not Found for RequestLimitDoctoral" etc. To add a key for these statuses, type in the appropriate values into the Customization table under System .. General in the Customization Manager. All fields must be filled out in the Customization table.
There is currently no way to turn off the request limit in the web interface. A request limit can be as high as you like, however (i.e. 2000 or 9999).
SUMMARY
In order to allow access to ILLiad and its various component parts, the following ports are required to be open.
Optional Ports
If you plan on using Z39.50 to search your local OPAC from within ILLiad, you will need to check that the ILLiad Client machines have access to the Z39.50 server over that port. This port differs from OPAC to OPAC so you will need to verify that value.
If you want to allow access to your ILLiad Server via Terminal Services, port 3389 should be opened. You can decide if you want to open this to particular ip address ranges or all ip addresses. You can also leave the port open and just turn on Terminal Services on the server as needed.
INFORMATION
In our testing, we've determined that the following searches work with a sampling of the shown databases. As more sites use the z39.50 link, this list will be updated with the latest information on compatibility. Compatibility consists of both searching and holdings importing in ILLiad.
AVAILABLE PROFILES
ILLiad currently supports the following OPACS: Aleph, DRA, Dynix, Geac, Innopac, Sirsi, and Voyager. These default profiles are available in the Customization Manager.
SEARCHING
The following systems have been tested and no problems were found: Innopac, Voyager, Sirsi, DRA, Aleph.
In the test systems we've used, Dynix and Geac were not able to be searched using the OCLC number.
IMPORTING HOLDINGS INFORMATION
The following systems have been tested and no problems were found: Innopac, Voyager, Sirsi, DRA, Aleph, Dynix, and Geac.
OTHER SYSTEMS
The following systems have been tested and are not currently compatible with ILLiad: VTLS, Notis.
The following systems were not tested with ILLiad: Horizon.
INFORMATION
ILLiad uses Z39.50 searching profiles to let you customize your Z39.50 searching abilities. This article shows some examples of the the default searching profiles for different OPACS, as well as discusses ways to change the profiles to better enable the mode of searching you would like to achieve.
AVAILABLE PROFILES
ILLiad currently supports the following OPACS: Aleph, DRA, Dynix, Geac, Innopac, Sirsi, and Voyager. These default profiles are available in the Customization Manager.
SAMPLE PROFILE
The following is a sample profile from an INNOPAC site:
| System Number Search | @attr 1=1007 "<#SystemNumber>" |
| Title Search | @attr 1=4 "<#Title>" |
| Author Search | @attr 1=1 "<#Author>" |
| ISSN Search | @attr 1=7 "<#ISSN>" |
| ISBN Search | @attr 1=7 "<#ISBN>" |
| Date Search | |
| Keyword Author Search | @attr 1=1 @attr 4=2 @attr 3=3 |
| Keyword Title Search | @attr 1=4 @attr 4=2 @attr 3=3 |
These values are in a format called Prefix Notation. Each Z39.50 attribute is shown, along with an ILLiad field tag (like this: <#ILLiadFieldTag>). When the search is run in ILLiad, the field tag is replaced with the appropriate word from the ILLiad record.
As an example, if the z39.50 use attribute for doing a title search on your OPAC is 4, then the sample from above, @attr 1=4 "<#Title>", will work. Generally, without any other search modifiers, the title search as shown will only search for titles starting with the search words. It will not by default search anywhere in the title for the title information from the field tag.
The Keyword Author and Keyword Title searches don't have field tags - they are used by the system to denote a combination of search attributes that will result in a keyword search for the author and title respectively. In the example above, the Z39.50 Position attribute (3) is modified to be 3 (any position in field), allowing a keyword search to happen.
CHANGING PROFILES
Changing the profile is as simple as changing the entries in the Customization Manager for the selected server. You will need knowledge of your server's z39.50 setup and profile information in order to make changes to the profile in ILLiad. (Incorrect profiles will simply not work - they should not cause any problems on the server end.)
An example of something a site may want to change is the Author Search. The default profile in ILLiad runs an exact Author Search - it will not search other pieces of the author to make a match. A search for Ayn Rand may not return the same results as a search for Rand, Ayn. One way to fix this is to change the author search to be more like a keyword author search. From the example above, if I change the author Search from @attr 1=1 "<#Author>" to @attr 1=1 @attr 4=2 @attr 3=3 "<#Author>" then author searches should be more flexible.
SUMMARY
OCLC ILLiad has been tested with Windows Server 2003, Standard Edition, and is completely compatible. Once ILLiad is setup, the usage of ILLiad is no different when using Windows Server 2003 vs. Windows 2000 Server.
By default, Internet Information Server 6 is more secure than the older versions, and requires specifying which ILLiad files are allowed to be executed. This article covers the differences between the Windows 2000 Server install (which is in the documentation) and Windows 2003.
INSTALLING INTERNET INFORMATION SERVER 6 (IIS)
By default, IIS is not installed when you install Windows Server 2003. After installing, you can choose to make the server an Application Server, and choose which Application environments you want to add. Using this Wizard, you can select IIS for installation.
INSTALLING SQL SERVER 2000
SQL Server 2000 is only supported on Windows 2003 Server, Standard Edition, with Service Pack 3 or greater installed. The system will not let you run with less than SP3.
CONFIGURING INTERNET INFORMATION SERVER 6 (IIS)
After following the current ILLiad installation instructions for the web pages, you must enable the ILLiad.DLL application file in order for it to be allowed.
Under Computer Management, chooise Services and Applications, then Internet Information Server. Choose Web Service Extensions, then choose Add a new Web Service extension.
For Extension Name, you can type ILLiad DLLs.
Click Add, and find the ILLiad.DLL file on your server (usually in the c:\inetpub\wwwroot\illiad\ folder).
Click the check box for "Set extension status to Allowed". Hit OK.
You will also need to add the ILLiadReports.DLL file (usually in the c:\inetpub\wwwroot\illiad\webreports\ folder) and the isapi_redirect.dll file for OpenURL (usually in the c:\illiad\OpenURL\jakarta\bin\ folder).
After adding and setting up those three extensions to be allowed, stop and restart IIS before testing the ILLiad pages.
SUMMARY
After updating to version 6.1 of the ILLiad Client, you may notice that in a shared server configuration all of your requests update as the reason other for cancellations and conditionals regardless of the reason chosen in the list. This is because of a change in 6.1 that allowed all shared servers to split out those reasons for each site. In order to use this, though, you must have a list of cancellation reasons in your tables for each NVTGC code.
The update for 6.1 did not populate these tables automatically because some shared server installations had already split out their cancellation reasons ahead of time. Below is a script that will allow you to take your current reasons and replicate them for all of your NVTGC codes in your database. Be sure to backup the database before running such a script.
EXAMPLE
Connect to your ILLData database using SQL Enterprise Manager on your SQL Server as either the "sa" user or Windows authentication. Take this example script below and run it on your ILLData database for each NVTGC code, replacing the piece of the script in red with your NVTGC code
use ILLData
go
insert into LendingReasonsforCancellation
select ReasonNumber, 'ABC', Reason, DefaultNote, OCLCCode, DoclineCode, RLINCode
from LEndingReasonsforCancellation where NVTGC = 'Lending'
go
insert into LendingReasonsforCond
select ReasonNumber, 'ABC', Reason, DefaultNote, OCLCCode, DoclineCode, RLINCode
from LEndingReasonsforCond where NVTGC = 'Lending'
go
insert into ReasonsforCancellation
select ReasonNumber, 'ABC', Reason, DefaultNote
from ReasonsforCancellation where NVTGC = 'ILL'
go
insert into DocDelNotFoundReasons
select ReasonNumber, 'ABC', Reason, DefaultNote
from DocDelNotFoundReasons where NVTGC = 'ILL'
go
SYMPTOMS
When opening the Z39.50 Search form from the Borrowing or Lending Search Forms or the General Update form, you receive a Class Not Registered error.
CAUSE
The Z39.50 components that ILLiad needs to perform the search are missing.
RESOLUTION
The OCLCILLiadZ3950Setup.exe program must be run on any client machines that will be using Z39.50 searching. This update to ILLiad adds the components needed for Z searching. This file is available in the 6.3.2.0 ClientUpdates folder on your server.
SYMPTOMS
When trying to run any component of ILLiad, you receive an error that the system can not load the IDAPI service library file NTWDBLIB.DLL.
ERROR MESSAGES
Vendor Initialization Failed; Can not load IDAPI service library file NTWDBLIB.DLL.
CAUSE
The Borland Database Engine (BDE) can not find the Microsoft SQL Server drivers in order to access the database.
RESOLUTION
There are 2 ways to fix this problem: Reinstall the drivers from the original CD, or reinstall the ILLiad Client using the setup program.
To reinstall using the Microsoft SQL Server CD, run the default installation program. One of the options is to do a Drivers Only installation. This will replace the missing drivers.
To reinstall the ILLiad Client, run the setup.exe for ILLiad in the ILLiad share. You can use this approach on either the client or server machine.
SYMPTOMS
When logging into Microsoft SQL Query Analyzer or any ILLiad program, the error message appears "Login failed for user 'username' Reason: Not associated with a Trusted SQL Server connection".
CAUSE
The Security Authentication setting for the SQL Server is set to Windows Only. Therefore, the illiad usernames or the sa user can not connect to the database, even if the logins exist and are setup correctly.
RESOLUTION
Change the Security Authentication setting to SQL Server and Windows for the SQL Server. Open the Microsoft SQL Enterprise Manager, right click on the SQL Server icon for your ILLiad server and select Properties. Select the Security tab and choose the SQL Server and Windows radio button. Then click the OK button to save changes. Click "Yes" to re-start the SQL Service if prompted to do so. Also, be sure that the sa username within SQL Server has a secure password assigned to it and is not blank. You can change that under Security .. Logins within the SQL Server and double-clicking on the sa username to reset the password.
SYMPTOMS
When attempting to use the ILLiad Web Pages, anytime a user presses any button, they'll receive either a 500 error or a specific error of "BDE cannot be initialized".
ERROR MESSAGES
In order to see the specific error reported in Internet Explorer, you need to make sure that the "Show Friendly HTTP Error Messages" option in IE is turned off. This is under the Tools|Internet Options|Advanced tab.
The error you will receive is:
Exception: EDBEngineError
Message: An error occurred while attempting to initialize the Borland Database Engine (error $2B05)
CAUSE
Permissions have changed on the ILLiad server. In many cases, these permissions could have changed in the past at some point, and just recently went into effect when the server was rebooted. The ILLiad Web DLL remains resident in memory once loaded, so in many cases, a problem won't be seen until a reboot.
RESOLUTION
You need to reset the permissions for the IUSR anonymous user. In the commands below, replace IUSR_ILLIAD with the anonymous user that your IIS web server is set to use. Also, if you have your web pages stored in a location other than c:\inetpub\wwwroot\illiad\*.* then you'll need to change that path as well (or any other paths that are different on your server). These commands will add the anonymous user access back to the necessary paths, leaving all other permissions settings unchanged.
Run the following 4 lines from a command prompt on your server:
cacls "c:\program files\*.*" /E /G IUSR_ILLIAD:R
cacls c:\windows\temp /E /G IUSR_ILLIAD:F
cacls c:\windows\system32\*.* /E /G IUSR_ILLIAD:R
cacls c:\inetpub\wwwroot\illiad\*.* /E /G IUSR_ILLIAD:R
This script gives read permission to the anonymous web user to the directories listed as well as write access to the temporary windows directory. Be sure to check path names and the value for the anonymous user in the script before running it on your server. Also, note that after changing permissions on the server, you should reboot the server to reset the web dll and verify that all changes have successfully applied.
MORE INFORMATION
The CACLS command will let you change permissions for any folders on your server:
CACLS: Displays or modifies access control lists (ACLs) of files
CACLS filename [/T] [/E] [/C] [/G user:perm] [/R user [...>
[/P user:perm [...> [/D user [...>
filename Displays ACLs.
/T Changes ACLs of specified files in
the current directory and all subdirectories.
/E Edit ACL instead of replacing it.
/C Continue on access denied errors.
/G user:perm Grant specified user access rights.
Perm can be: R Read
W Write
C Change (write)
F Full control
/R user Revoke specified user's access rights (only valid with /E).
/P user:perm Replace specified user's access rights.
Perm can be: N None
R Read
W Write
C Change (write)
F Full control
/D user Deny specified user access.
Wildcards can be used to specify more that one file in a command.
You can specify more than one user in a command.
Abbreviations:
CI - Container Inherit.
The ACE will be inherited by directories.
OI - Object Inherit.
The ACE will be inherited by files.
IO - Inherit Only.
The ACE does not apply to the current file/directory.
SYMPTOMS
You receive an I/O Error 32 or a Path Not Found error when opening the Borrowing Search form.
ERROR MESSAGES
I/O Error 32.
Path not Found.
CAUSE
You are missing a file needed by ILLiad.
RESOLUTION
If you don't use RLIN, make sure that the RLINTemplate key in the Customization Manager is set to "No". If you do use RLIN, make sure that the RLINTemplates key is pointing to the correct folder for the RLIN Macros.
If you don't use Docline, make sure that the c:\illiad\docline folder does NOT exist. If it exists, it expects to find macros in it. If you do use Docline, make sure that the Docline macros are in the c:\illiad\docline folder (and not in a subfolder under that one).
MORE INFORMATION
This has been fixed in ILLiad Client version 6.1 which will be the next ILLiad Client release.
SYMPTOMS
If a user at a Shared Server Site has multiple logins set up in its logon.txt file (located in the C:\illiad folder) then the ILLiad Client will display the e-mails (from the e-mail routing feature) and Custom Queues for the first site listed in that file.
CAUSE
ILLiad is designed to read the first site code in the logon.txt file when determining which e-mails and custom queues to display in the ILLiad client.
RESOLUTION
Re-organize the list in the logon.txt file so that the appropriate site code is the first in the list. The e-mail templates and custom queues for that site will then be used. This is usually only a problem for those staff members who need to access more than one site for ILLiad processing. It is also acceptable to duplicate email routing and custom queue options for those sites so that they are available in more sites.
SYMPTOMS
When the SQL Server Agent attempts to run the ILLiad Connector batch files, it immediately returns a status of "Failed".
ERROR MESSAGES
If you right-click on the job and choose Job History, you will see an error like this:
The job failed. The Job was invoked by User MACHINENAME\ACCOUNT. The last step to run was step 1 (Run ILLiad Connector).
If you click the checkbox to view details, then you will see this or a similar additional error:
Executed as user: MACHINENAME\ACCOUNT. ...nformation ************************ C:\WINNT\system32>REM C:\WINNT\system32>REM This batch file is what the SQL Agent runs when it is scheduled to run. C:\WINNT\system32>REM C:\WINNT\system32>REM There are 4 possible commands you can send the Connector. They are: C:\WINNT\system32>REM C:\WINNT\system32>REM BorrowingDownloads - downloads statuses like Shipped, Conditional, etc. C:\WINNT\system32>REM LendingDownloads - imports new requests as well as conditionals and renewals C:\WINNT\system32>REM BorrowingUpdates - updates items to received or returned and requests renewals C:\WINNT\system32>REM LendingUpdates - updates as conditional, cancelled, shipped, etc. C:\WINNT\system32>REM C:\WINNT\system32>REM Each of these can be done individually or at the same time, by adding C:\WINNT\system32>REM them to the same command line. C:\WINNT\system32>REM C:\WINN... Process Exit Code -1073741787. The step failed.
CAUSE
The SQL Server Agent, in order to run a CmdExec type job (system commands, external applications, etc.), must have permissions. Only Administrator (local/domain) level accounts on the NT/2000 machine have permissions to run this type of job by default.
Another cause could be that the ILLiadVersion6Update.exe was not run on the server where the ILLiad Connector is running.
RESOLUTION
IF the ILLiadVersion6Update.exe has not been run (it would show under Add/Remove Programs if it had been installed), you can run the executable from the Setup .. ClientUpdates .. 6.0.0.1 folder. It is the same file that was run on the client machines.
There are 3 possible solutions to the permissions issue: Changing the account that the SQL Server Agent uses to run (recommended), overriding the setting that resticts the CmdExec jobs being only run by Admin accounts, or using a different scheduling software to run the ILLiad Connector batch files.
To change the account that the SQL Server Agent uses to run, open the Services dialog, find SQLSERVERAGENT, right-click and choose properties, click the LogOn tab and put an Administrator level account and password into the fields provided. Stop and restart the service.
To allow all users the ability to run the SQL Server Agent CmdExec jobs, right click the SQL Server Agent under Management using the SQL Server Enterprise Manager. Select the Job System tab. Under "Non-SysAdmin job step proxy account", uncheck the "Only users with SysAdmin privileges can execute CmdExe and ActiveScripting job steps. The system will prompt you for an Administrator username, password, and domain. Fill in these 3 items and hit OK.
If you elect to use a third-party scheduling software, just run the batch files as needed. The default schedule is:
USING THE WINDOWS TASK SCHEDULER
The Windows Task Scheduler is another way to run the ILLiad Connector. It is part of Windows 2000 Server, as well as Windows NT 4.0 Server machines that have had the installation of the Offline Browsing Pack, a component of Internet Explorer 5. This method is recommended if the SQL Server database is not on the ILLiad server machine.
To access the Windows Task Scheduler, follow these steps:
The new task will appear in the Scheduled Tasks applet in Control Panel. If you want to modify a task, right-click the process and select Properties to display an advanced dialog box where you can change the task parameters.
SYMPTOMS
When trying to perform z39.50 searches, you receive a file not found error for yaz.dll.
CAUSE
Missing files in the directory where the ILLiad Client resides will cause this error. Make sure the following files are in the directory with the ILLiadClient.exe file:
These files are installed when you run the z39.50 setup program that comes with ILLiad version 6.3.
RESOLUTION
Replacing the files will correct the problem.
ILLiad can use a Microsoft SQL Server 2005 database when the compatibility level for the database is set to SQL Server 2000 (80). If performing a new ILLiad installation, the compatibility level can be changed after the ILLiad server installation application has run.
To set the compatibility level in SQL Server 2005, perform the following:
SUMMARY
The RequestAddDefaultRequestType key allows you to change the default RequestType value that is assigned to transactions manually entered into the ILLiad Client.
This key appears in the ILLiad Customization Manager under System - General. Valid values for this key are Article or Loan only. The default value for this key is Article.
SUMMARY
ILLiad Anonymous User Permissions
ILLiad requires that the Anonymous User Account (generally, but not necessarily ALWAYS IUSR_Servername) and the Launch IIS Process Account (generally, but not necessarily ALWAYS IWAM_Servername) have Read and Execute permissions on the server to the following directories in order to properly run the ILLiad.dll through IIS:
" C:\Program Files\Common Files\Borland Shared\BDE
* C:\WinNT\temp
* C:\WinNT\System32
* C:\Inetpub\wwwroot\ILLiad\ (or whichever directory is your default ILLiad web directory).
In addition, both the Anonymous User Account and the Launch IIS Process Account also need to have Write access to the C:\WinNT\temp folder for the ILLiad.dll to function properly.
ILLiad Share Permissions
All ILL staff/employees who will be using the ILLiad Client will need to have read access to the ILLiad Share in order to run the ILLiad Client.
In the case of locally installed clients, the share referred to here essentially exists as a local directory on each client machine, without having to be shared for other users. In such cases, the server side ILLiad share either doesn't exist or is not used by the client machines. Special share permissions are not generally required.
PDF Share Permissions (If using the Electronic Delivery option.)
All ILL staff/employees who will be using the ILLiad Client to post Electronic Documents will need to have read/write access to the PDF Share in order to post electronic documents to the PDF share on the ILLiad server.
MORE INFORMATION
There is a separate KB article on how to fix the Anonymous User Permissions here.
SUMMARY
When setting up ILLiad routing rules that originate in the Borrowing module and route transactions to the Doc Del module (or vice versa), the ProcessType value in the Routing table should be set to the transaction's original module and the NewProcessType value should be set to the destination module.
EXAMPLES
To route a transaction to a special status in Document Delivery when it is routed to Doc Del from Borrowing, you would need to set up a routing rule like the following example:
| Field Name | Value |
|---|---|
| RuleNo | 6 |
| RuleActive | Yes |
| ProcessType | Borrowing |
| TransactionStatus | Awaiting Document Delivery Processing |
| MatchString | Whatever your criteria might be. Example: u.Status = 'Faculty' |
| NewProcessType | Doc Del |
| NewTransactionStatus | Awaiting Special Doc Del Processing |
| RuleDescription | Moves transactions meeting my criteria to Awaiting Special Doc Del Processing when routed to Doc Del from Borrowing. |
To route a transaction to a special status in Borrowing when it is routed back to Borrowing from Doc Del, you would need to set up a routing rule like the following example:
| Field Name | Value |
|---|---|
| RuleNo | 6 |
| RuleActive | Yes |
| ProcessType | Doc Del |
| TransactionStatus | Awaiting Request Processing |
| MatchString | Whatever your criteria might be. Example: u.Status = 'Faculty' |
| NewProcessType | Borrowing |
| NewTransactionStatus | Awaiting Failed Doc Del Faculty Processing |
| RuleDescription | Moves transactions meeting my criteria to Awaiting Failed Doc Del Faculty Processing when routed to Borrowing from Doc Del. |
SYMPTOMS
Setting up a routing rule using the Routing table in ILLiad will not work for requests imported via the ILLiad Connector if the processtype is Borrowing or Doc Del.
CAUSE
We have confirmed this as a bug.
WORK AROUND
If the statuses you are using as the routing trigger are specific to Borrowing or Doc Del (and not in Lending), then you can change the ProcessType in the routing table to be Lending, leaving the NewprocessType = Borrowing or Doc Del. This will allow the Connector to use the routing rule.
RESOLUTION
This was fixed in the 6.3.0.0 Connector release. Updating to this connector version should fix the problem.