Last revised: December 14, 2017
Problems are organized by type of functionality. Click a link for the type of problem(s) you want to see. Functions with no current problems are noted.
Customized settings are lost
Click a link to see problems resolved in the most recent client versions:
Current known problems
There are several possible causes for the corruption of files containing customized settings:
- An application, process, or Windows itself shut down abnormally during a file write operation.
This usually happens when something goes wrong while the file is being saved. The problem could be internet connectivity if the program is signed in to a service, or your computer suddenly loses power. Other problems include network issues, available computer resources, another running app or unstable process. If any of these things interrupt the process of writing to the file, the entire file may not be written or the hard drive “table of contents” does not get updated.
- A physical hard drive is fragmented.
This only applies to physical hard drives. Solid state drives are not affected. A fragmented hard drive creates more pieces in which the options.xml file will be stored. If the disk is defragmented, and the file can be stored in contiguous clusters, the write time to put the file back is reduced.
- Antivirus software
Occasionally, antivirus software will register a false positive on the options.xml file, deleting it when the client closes and releases the file.
- Windows folder redirection is storing all AppData settings on a shared network
Under certain circumstances, having the AppData settings on a shared network will cause an individual user’s options.xml file to be deleted each time they close and reopen the client.
If you are having problems with losing your customized settings, please contact OCLC customer support for help.
False “Unidentified publisher” system warning in Windows 7, 8/8.1, and Windows 10 upon startup of client 2.63
If you use version 2.63 of the Connexion client in Windows 7, 8/8.1, or Windows 10, you receive the following Windows User Account Control (UAC) system warning each time you start the client:
An unidentified program wants access to your computer.
"C:\Program Files (x86)\OCLC\Connexion\Program\Connex.exe"
The enhanced security in modern versions of Windows triggers UAC when the client is started. Click Yes to grant permission. The client will open and run as expected.
Downloading and installing the client Auto-fix will suppress UAC prompts when opening the client.
(Added 04/21/2011; updated 09/21/2018)
You may be denied access to OCLC files after you upgrade, preventing you from running the client
You may receive an "Access denied" error the first time you run the client after installing. The error message lists a file starting in the X:\Program Files\OCLC\Connexion\Program folder and may list others. Access may be denied to the following files, among others:
To run the client in the users group, follow this one-time procedure:
- Log on to your workstation as Administrator.
- Add the User to the Administrators group.
- Log on as the User.
- Start the client. A series of progress bars will appear. When the progress bars finish processing, the client will open.
- Remove the User from the Administrators group.
- Log on as the User. Restart the client. You do not have to repeat this procedure.
During upgrade, installation fails; you are asked for Connexion.msi path
In some cases, the upgrade installation may fail with a message asking the path to your Connexion.msi file. Please contact OCLC Customer Support for help in resolving this problem:
- E-mail: email@example.com
- Telephone: 1-800-848-5800 (USA) or +1-614-793-8682
Available: 7:00 a.m. to 9:00 p.m., U.S. Eastern time, Monday–Friday
The installation program may re-run the first time you open the client after installing the client-only software
If this problem occurs, it happens only the first time you run the new version. The problem does not affect the client's performance.
The first time you use the client shortcut icon () on the desktop to open the client after upgrading, you may get an error that prevents the shortcut from working
This problem may occur only for those who use Windows XP or Vista and run the client under a User security level. If this happens, create a new shortcut and delete the non-functional one:
- Navigate to the Connex.exe file in X:\Program Files\OCLC\Connexion\Program\ (X = the letter of your hard drive).
- Right-click the Connex.exe file, and then click Create Shortcut.
- Drag the shortcut to the desktop. It becomes an icon.
- Right-click the original shortcut icon that did not work and click Delete to remove it from the desktop.
Tip: To shorten or change the name of the icon you created, single-click the text attached to the icon, and then single-click again to select and edit the text.
If you do not uninstall the client before upgrading, changing the "Install for everyone or just for you" setting during upgrade makes the client inoperable
Please note that OCLC recommends uninstalling before you upgrade to prevent possible problems like this one.
When you upgrade the client without first uninstalling, in the window where you select an option to install for everyone who uses the workstation or just for you, you must select the same option you selected during your original installation. If you don't and the client becomes inoperable, you must uninstall and re-install the new version.
To determine which selection you made for the original client installation, check the location of the OCLC Connexion client desktop shortcut:
- If you selected installation for you only, OCLC Connexion Client is listed in X:\Documents and Settings\[ your username] \Desktop, where X = the letter of your hard drive.
- If you selected installation for everyone, OCLC Connexion Client is listed in X:\Documents and Settings\All Users\Desktop.
( Added 02/11/2008)
The client may be missing the graphical diacritics and special characters selection box after you upgrade if you did not uninstall the previous client version
The Enter Diacritics and Special Characters window ( Edit > Enter Diacritics) has both pictures of diacritics and characters and a drop-down list of their names, from either of which you can choose a character to enter in a record or a search. If you are missing the graphics in this window, close the client and all open programs, and then close down and re-start your workstation. ( Note: Even when the graphics are missing, you can still select a character from the list.)
An OCLC Gateway export destination you set up before upgrading may not work after upgrading if you did not uninstall the previous client version
If you set up an OCLC Gateway export destination in a previous version of the client, but export does not behave as expected after you upgrade, check or reset options in Tools > Options > Export:
- In the Export tab, select the OCLC Gateway export by name in the Destinations list and click Edit.
- In the OCLC Gateway Export - Local System Settings window, check and correct settings if needed.
Change to heading appearance of headings in a browse list when the ending punctuation of the heading is different
As part of the Connexion install, changes have been made to authorities indexing. These include the resolution of the longstanding problem that resulted in misleading subfield codes:
“Occasionally, a heading appears in browse results with a subfield code that is misleading. However, when you view the record, the subfield code that appears in the results list is not present in the record.
An example of this is browsing the LCSH index for the heading Noah's Ark. In the root index, the heading is presented as $t Noah's Ark; however, when you view the record, the heading Noah's Ark appears in $a, not $t. There is only a single subject authority record for Noah's ark, in which the heading appears only in $a (LCCN sh 85092133). But the text Noah's ark appears in $t in 9 other authority records.”
However, as part of the new indexing, users will find a change in the appearance of headings in a browse list when the ending punctuation of the heading is different. This change to indexing results in multiple listings:
Poe, Edgar Allan, $d 1809-1849 1 record Poe, Edgar Allan, $d 1809-1849. 2 records Poe, Edgar Allan, $d 1809-1849 $c (Spirit) 1 record
Poe, Edgar Allan, $d 1809-1849 E1. 1 record E2. 1 record E3.$t Fall of the house of Usher  1 record E4.$ Gold bug  1 record
In the Expanded list, both the  and  relate to the first record in the Root list, and E3 and E4, that have a period prior to the $t are represented in the second entry in the root list that contains a period at the end of the $a.
Connexion sorts words that include diacritics out of order in WorldCat derived and keyword search results
(Partly resolved with system changes November 2005 - resolved for derived search results only)
When WorldCat derived and keyword search results include words with diacritics, the records sort out of sequence with words that do not have diacritics, whether you use the client or the browser interface.
- A personal name derived search for lutz,m, results in the following order of records retrieved: Lutzki, Moses, Lutzky, M. , Lutzky, Morton, Lütze, Max, Lützeler, Marga.
- A personal name keyword search for lutz, m* returns Lutz, Madeleine, Lütz, Manfred, and Lutz, Marcel, bu t Lütz, Manfred incorrectly appears first in the sequence.
Workarounds: (1) In the client only, you can click the column heading in the list to re-sort, although the re-sort is not always 100% correct, or (2) in the client or browser, browse (scan an index) for the term instead–Connexion normalizes the headings by removing the diacritics, so the results display correctly.
Incorrect record counts in browse results for authority records
Browse results for authority records display headings and record counts from a list that the system does not update immediately when authority records are added or replaced. In the past, updates were immediate but caused an adverse effect on overall system response time. This was formerly a problem with WorldCat search results.
Caution: Copying and pasting browse terms that contain diacritics to browse the LC authority file may prevent Connexion from normalizing results correctly
If you paste terms that contain diacritics into the client from another program or file to browse the LC names and subjects authority file, Connexion may not be able to normalize the results correctly.
Caution: Whether to retain or omit a comma in a browse term for the LC names and subjects authority file depends on the index you browse
Retain a comma in a term you use to browse the LC authority file only when you browse the personal name index and the topical index. Exclude a comma from a term when you browse the LCSH index.
Example: Browse for authors, english in the topicals index. Browse for authors english in the LCSH index.
Searching authority records for headings that contain the percent (%) symbol
Do not use the % symbol when searching the authority file. In some cases, keyword searches that includes the percent (%) symbol may result in an error message.
Browsing authority records for personal names that have abbreviations followed by periods requires special treatment
Substitute a space for the period in a personal name that contains an abbreviation followed by a period.
Example: Enter sca pn:L , Harry. Do not enter L., Harry or L, Harry.
Internet Resources appear under Books in the group list, but actually are correctly retrieved by your search
Currently, records that meet specific requirements (presence of 856 with appropriate indicators) are given the primary document type of Internet Resources, but Connexion group lists do not yet include Internet Resources as a separate group heading. Instead, Internet resource records are included under Books in group lists, regardless of how the fixed field is coded. These groupings are for display purposes only, and reflect the actual format of the records, except for the inclusion of these Internet resources in any format.
For example, the search pb:naxos and hl:trios and mt:rec retrieves records for streaming video that are grouped under the Books format, even though the records are in the sound recordings format, with 006 fields for electronic resource/computer files, an 007 for sound recordings, and an 007 for the computer file.
You can limit a search to non-Internet items (not mt:url) to retrieve and display non-Internet items under the "correct" format heading in a group list. If you intend to retrieve both Internet and non-Internet items, be aware that any Internet resource records that match the search will be found under the Books format if you get a WorldCat group list.
The first time you display a WorldCat record using a new user profile, the record window is not maximized in the client window.
The first WorldCat record displayed using a new user profile is a truncated view in the upper left part of the work area in the client window. To maximize the record window, use Window, Tile Vertically or Tile Horizontally.
CJK script searches enclosed in double quotation marks are not working correctly
Enclosing a WorldCat search string in quotation marks ( "[search string"]) retrieves only records containing the exact search string matched character by character. Currently, however, if the search string is a CJK script string, the results include both records containing the exact string (correct) and records containing each character in the string (treated as a word) (incorrect).
Overwrite/insert editing mode changes incorrectly
Sometimes the editing mode shifts incorrectly in the client from overwrite to insert or vice versa. So far, the cause, circumstances, and frequency of this problem are undetermined.
Highlight with mouse from right to left to delete a field may shift data in next field
Has been added as a "Caution" to client documentation and Help.
Edit a record, then save it, and then lock the record. Your edits are lost.
The client gives no warning but does not retain your edits in this workflow scenario.
Save constant data from the local save file to the online save file fails if online record already has a record with the same name
Has been added as a "Caution" to client documentation and Help in Cataloging/ Use Bibliographic Constant Data, "Create, edit, or delete bibliographic constant data."
For online constant data (CD) only, diacritics and special characters in CD name and CD My Status cause errors
Has been added as a "Caution" to client documentation and Help in the same topic specified in the known problem directly above. The cautionary note has a list of the characters that cause errors.
250 field in Constant Data overwrites existing 250 field when applied
The client does not recognize that the 250 field is repeatable. As a result, a 250 field in a constant data record will overwrite an existing 250 field when constant data is applied to bibliographic record.
Workaround: Enter the text you want to add to the 250 field in a tag that is not often used, and then change the tag number to 250 after you apply constant data.
Validation set to None may have implications for offline services
If you have validation set to None for setting holdings (Tools > Options > General / Validation Options), invalid characters in records will not produce an error message when you update holdings on an existing record or delete your holdings. However, the system will convert invalid characters to fill characters in your archive files.
Inappropriate message may appear when exporting authority records
On occasion, you may receive the following message when you export authority records: "This main entry exists in another authority record: LCCN=n ######## ARN=oca########." You receive the message as a result of a process that normalizes the main entry to help reduce duplicate records. Currently, tags are not considered in the normalization process.
The message occurs when you validate the record (Edit, Validate) before exporting or when you have the validation level set to "Full" in the Tools, Options, General tab (click Validation Level Options).
If you used Edit, Validate, you can go ahead and export with no problem. If you have the validation level set to "Full," change it to "Basic" and then export the record.
False error message may result from system duplicate detection when new authority records are added or master records are replaced
The system uses NACO Normalization rules to match the 1XX heading of any record you want to add or replace against the 1XX and 4XX name headings to detect duplicates. However, the system incorrectly ignores the first comma in subfield a, which results in an incorrect validation error message— This main entry exists in another authority record: LCCN=xx xxxxx ARN=ocaxxxxx. If you receive this message as a result of this problem, and the new/replace heading is not a duplicate, click OK to close the message, and simply re-issue the Add or Replace command to successfully add or replace the record.
Space required between subfield delimiter and heading text in version 2.63
Client version 2.63 requires a space between other characters in the text of the field and the subfield delimiter to control a heading. The move to support all Unicode characters has changed the behavior of Latin Letter Aveolar (U+01C2) that the client uses for the delimiter symbol. Reformatting the record before you control headings adds the spaces automatically.
Headings seem controllable but cannot insert them into bibliographic record
There are situations in which headings are presented as controllable, but when a user attempts to insert them the heading is not successfully inserted into the bibliographic record. An example of this is when attempting to control the heading:
600 10 Mah, Stuart $v Correspondence.
The following headings are presented in the Control Headings window:
Mah, Stuart ǂt Correspondence >> Mah, Stuart. ǂt Correspondence. [600 Partially-controlled]
Mah, Stuart ǂv Correspondence >> Mah, Stuart ǂv Correspondence. [600 Fully-controlled]
Mah, Stuart. 
ǂv Correspondence [Subdivision record]
Both headings are presented with the option to either Modify Heading or Insert Heading. But at this time, if a user attempts to insert the heading, other pages are presented but the user cannot successfully insert the heading.
The workaround for this problem is:
In the display window, one of your options is the name heading alone, without subdivisions.
Mah, Stuart. 
Click the Modify Heading button.
In the window, you should then see your subfield $v "Correspondence". Click the Append to Heading button beside it. The string is now formatted correctly:
Modified Heading: 600 10 Mah, Stuart $v Correspondence.
Click the Insert Heading button to insert the controlled heading into the bibliographic record.
(Updated 03/04/2014)Punctuation: After controlling a heading, the punctuation in the controlled heading differs from the punctuation entered, and/or from the punctuation present in the authority record. (REVISED)
Revised following system installation 05/15/2011. When controlling headings, the system matches headings against the authority file. This matching process invokes a normalization process, which collapses all punctuation and spaces, removes subfield delimiters and codes, and is not case sensitive.
If punctuation is incorrectly altered when you control a heading, uncontrol the heading, correct the punctuation, and leave the heading uncontrolled. See more information in Technical Bulletin 259R, Authorities System Changes about new punctuation rules for controlling headings.
A note about incorrect punctuation in the authority record. The following is a new recommendation:
- If the authority record is not punctuated correctly, then the controlled heading in the bibliographic record will contain the same incorrect punctuation.
- In this case, OCLC prefers that you control the heading that contains the incorrect punctuation and then report the incorrectly punctuated authority record to firstname.lastname@example.org.
Currently, only series headings coded as 8xx are candidates for controlling. While series headings are access points, the primary function of the 4xx fields is to reflect the transcription of series statement on an item, and secondarily to provide access as a series added entry. Currently, if 440 fields were controlled, the 'correct' 440 heading text could be incorrectly changed to the new heading in the authority record. This would result in the loss of the field's primary function of transcribing the series statement as found on the item.
Series headings in 8XX fields
Although 8XX fields are controllable, if an authority record does not exist for the title part of a series name title heading in fields 800, 810, 811, or 83X, and you try to partially control the heading (in addition to leaving the $v uncontrolled), the tag automatically flips from 8XX to 7XX.
Cannot control headings when the main heading and subdivision are the same
You cannot control a heading that repeats the same text as main heading and subdivision, as in the following example:
Example: 650 [blank] 0 History $x Study and teaching (Higher) $z Poland $x History
Currently, there is no workaround. You must leave headings uncontrolled when the main heading and subdivision are the same text.
Bibliographic record contains "controlled" 6xx headings with second indicators other than 0
In some bibliographic records, headings tagged as 6xx with indicators other than 0 (zero) are incorrectly highlighted as controlled headings.
Cannot control headings with subfield i followed by a relationship verb such as "contains"
You cannot control headings that begin with subfield i followed by a phrase that begins with a relationship verb; for example, "$i contains information".
Cannot control headings with open date (including hyphen) containing a geographic subdivision
You cannot control headings of the type:
650 0Israel-Arab Border Conflicts, 1949-$z Lebanon
These are cases when a pre-coordinated authority record ends in an open date (and includes a hyphen) and contains a geographic subdivision.
Currently, when attempting to control headings of this type online, the controlled inserted record in the bibliographic record appears as:
650 [blank]0 Israel-Arab Border Conflicts, 1949- ǂz z Lebanon.
A workaround for this problem is to add another subdivision that requires the Controlled Heading Window to open:
For example, enter the heading:
650 [blank]0 Israel-Arab Border Conflicts, 1949- ǂv Periodicals ǂz Lebanon
When the list of headings is presented, the line number associated with the correct form (Israel-Arab Border Conflicts, 1949- ǂz Lebanon) and the heading will be inserted without the incorrect character between the $z and Lebanon.
Transliteration, diacritics, non-Latin scripts
Incorrect characters displayed in diacritics picker with Windows 10
The diacritic picker in Connexion client is having some compatibility issues with Windows 10, resulting in incorrect characters appearing in the diacritics picker.
Reinstall the ALA BT Courier font from the OCLC folder to the Windows fonts folder.
- Close Connexion client if it is running.
- Navigate to C: drive > C:\Program Files (x86)\OCLC\Connexion\Program.
- Right-click ALACOUR.TTF and then select Copy.
Note: If you don’t see the TTF extension, check the Type column for Truetype font file.
- Press Windows key+r to launch the Windows Run box.
- Enter fonts in the Windows Run box and then press Enter. This opens the Windows Fonts folder.
- Press Ctrl+v to paste the font file
- If you receive a message that the ALA BT Courier font is already installed, select Yes to Replace it.
- If you are prompted for an administrator password or confirmation, enter the password or provide confirmation
- Launch Connexion client.
- Open a record and bring the diacritics picker up. Everything should appear as expected.
Cursor does not always display at the end of the text when non-Latin script characters are pasted into a field
When non-Latin characters are pasted into a field, the cursor may display in the middle of the text instead of at the end.
Latin Letter Aveolar (U+01C2) and Khosian Languages
This character is also the subfield delimiter symbol in the client. The client interprets this character as a subfield delimiter and errors will occur if you attempt to use it in your bibliographic records for items in Khosian languages. Work in Record Manager if you need to use this character in your bibliographic records.
MARC-8 Characters Verify no longer highlights non-MARC-8 characters
If you put characters that are outside of the MARC-8 character set into a record and perform the MARC-8 Characters Verify command, the change to accepting all Unicode characters prevents this function from isolating characters that are not part of the MARC-8 character set.
Searches using characters above Unicode Plane Zero return incorrect results
Connexion client is currently unable to send the correct characters if characters entered are above the basic multilingual plane (BMP). The client handles Unicode characters in the BMP, which contains characters with a code point between U+0000 and U+FFFF. The BMP includes all the characters originally supported for cataloging in addition to many more. However, some language characters are found using supplementary planes and code points, such as CJK Unified Ideographs Extension B which has characters between U+20000 and U+2A6DF.
Workarounds: (1) In the client, change search argument to use only MARC-8 characters, could be switching to a name or subject that is all MARC-8 instead of what was originally entered. (2) Use Record Manager.
CJK E-Dictionary search results are incomplete
When you use the E-Dictionary Search window (that is, click Tools > CJK E-Dictionary, enter an input code or character in the search box, select an input method and a script, and click Find), the E-Dictionary Search Results window shows only the EACC data in the first column. The other columns are missing data.
Workaround: In the E-Dictionary Search Results window, double-click the EACC entry. The E-Dictionary Entry window opens, showing all of the codes that are supposed to display in the search results.
Using the keystroke shortcut <Ctrl><D> to enter a subfield delimiter and code in non-Latin script data may not switch you back to the language/keyboard you were using, as it should, or may switch you to a different language.
When you are entering non-Latin script data and use <Ctrl><D> to automatically switch to the English keyboard and back for entering a subfield delimiter and code, the client may not switch you back to the keyboard you were using after you enter the delimiter and code. You may remain in the English keyboard or you may be in a different keyboard.
To switch to the keyboard you need, click the language indicator in the Windows system tray (small blue box with two-letter codes), and then click the language/keyboard you need, or select by using the Windows default keystroke Left <Shift><Alt> to cycle through the language indicator list.
In Connexion client version 2.00 and higher, the Microsoft Input Method Editor (MS IME) for Korean does not convert an existing Korean hangul character into a hancha or Chinese character
If you convert a hangul syllable into a hancha or Chinese character immediately after you enter it, the conversion works correctly. The conversion does not work if you highlight an existing hangul syllable and then try to convert. The IME does not allow you to choose a Chinese character. The problem occurs with hangul syllables in records; it does not occur when you convert a hangul syllable in the WorldCat quick search box on the toolbar (or in a text box in the Search WorldCat dialog).
Workaround: Copy the hangul syllable you want to convert and paste into the WorldCat quick search text box, convert it to a Chinese character, and then and copy and paste back into the record.
The Arabic transliteration tool handles some characters incorrectly
The list of incorrect characters has been added as a "Caution" in client documentation and Help in Cataloging/Use Non-Latin Scripts for Cataloging, "Catalog using Arabic scripts."
Other Persian transliteration problems
The Persian transliterator:
- Treats the romanized "th" as one character, Theh 062B. It should be treated as two characters, Teh 062A and Heh 0647.
- Does not transliterate characters following the romanized miagkii znak (prime mark) correctly.
Some diacritics/characters do not display correctly for those who use Arial Unicode MS font in Microsoft Office 2000
The version of Arial Unicode MS font included in Office 2000 (or lower versions) may cause some characters to display incorrectly. The problem has occurred, for example, with some diacritics and special characters in Vietnamese text. Upgrading to Microsoft Office 2003, which installs a version of the Arial Unicode MS font that includes a more complete character set for display, appears to solve the problem.
Unable to open external links in Online Help
The online help system in Connexion client is having some compatibility issues with some of the external web pages to which it links.Workaround:
If you are having difficulty opening an external web page, you can copy the web address from the Properties dialog, which is available on the right-click menu for the web link. To open the web site, you can then copy this information and paste it directly into address field for your browser. You can also search for the content on the OCLC Support site or open the links from the documentation that is found on the Connexion Support Web site.
Cannot maximize (re-display) Connexion client from a minimized position in the task bar.
When you minimize the Connexion client, it becomes an icon in the task bar on your desktop, and you should be able to maximize (re-display) it by clicking the icon. If you are unable to maximize the client from the task bar icon, use the following workaround.
Workaround: Click the Connexion client icon in the task bar, and then press and hold the Windows key () on your keyboard while you click the <Up arrow> key.
Catalogers can use Connexion client 2.00 and higher via a Citrix thin client, with caution and with some limitations
OCLC has completed limited testing using version 2.00 under Citrix access. Though most functionality appears to work under testing conditions, except the two functions listed below, OCLC does not guarantee that the client will work for everyone under Citrix, since server and system configurations vary from library to library.
The following are known limitations of using the client under Citrix:
- You cannot use macros (although staff at one library reported that their Citrix implementation contractor developed a customized way for them to use macros).
- Writing data to a file may not work. Examples of writing to files in the client include exporting records to a file and printing records, labels, or an accession list to a file. Writing data to a file under Citrix creates files on your remote server. Depending on the location of the files, you may not have access to them. Resulting error messages are "exceptions" that do not explain that this is the problem.
Updating holdings on records imported into the client via Z39.50 (Tools menu) does not work
If you use Update Holdings to add a Z39.50-retrieved local system record to WorldCat (the client imports the record as a workform), you receive a message that field 001 is missing the OCLC number. As a workform, the record should not have an OCLC number in field 001. This is a system error.
Workaround: Derive a new record from the Z39.50 imported record and then add to WorldCat using Update Holdings.
In client version 2.50, some Extended Latin characters do not export correctly when MARC-8 character encoding is used for export. (RESOLVED)
In client version 2.50, when Tools>Options>Export>Record characteristics>Character set is set to MARC-8, these characters will export as numeric character references instead of the actual character. These characters export correctly when UTF-8 is selected for export.
- Latin capital letter D with stroke
- Latin small letter D with stroke
- Latin small letter dotless I
- Latin capital letter L with stroke
- Latin small letter L with stroke
- Latin capital ligature OE
- Latin small ligature OE
- Latin capital letter O with horn
- Latin small letter O with horn
- Latin capital letter U with horn
- Latin small letter U with horn
(Added 03/10/2014) (Resolved 04/16/2014)