About right-to-left language features

Access is designed to display and print both right-to-left and left-to-right text. For best results, the program should use a font that contains both right-to-left and left-to-right language characters. Some fonts available with Office and bidirectional Windows operating systems contain both right-to-left and left-to-right characters.

If you choose a font that does not contain both right-to-left and left-to-right characters, existing text in one or both languages may be displayed using a secondary font, such as Tahoma. For further information, refer to 'Unicode support' in Microsoft Office Help.

You can check the spelling of both your English and right-to-left text in the Memo, Text, and Hyperlink fields. Just choose a dictionary that corresponds to the text that will be used.

When right-to-left text is checked, English words are ignored and not flagged as misspelled. Similarly, when English text is checked, right-to-left words are ignored.

The feature described in this Help topic is only available if support for right-to-left languages is enabled through Microsoft Office Language Settings.

In addition, to enable the right-to-left features in Microsoft Access, you must be running a 32-bit Microsoft Windows operating system that has right-to-left support— for example, Microsoft Windows 2000.

Access preserves expressions with left alignment and left-to-right reading order. Expression terms are preserved in left-to-right order to ensure the visual readability of expression statements that contain mixed text. As each statement character is entered, the expression display is dynamically updated.

The following table provides examples of bidirectional text that is used in expressions.

There are a few other considerations when using expressions with right-to-left languages:

• Access displays Structured Query Language (SQL) statements by using the same rules it uses for displaying expressions.
• Bidirectional control characters entered in expressions are removed prior to evaluating the expression to avoid possible conflicts.

Note  Bidirectional text used in the Expression Builder will "swap" certain neutral character pairs such as "( )" and "{ }" when the keyboard language is a right-to-left language. To avoid this, change the keyboard language to a left-to-right language or type the correct character.

Access 2000 (and later versions) provides full forward compatibility for database files saved in all previous versions of Access with right-to-left support.

Access supports use of the Hijri calendar in addition to the standard Gregorian calendar in all locales except Thai and East Asian locales.

If you open an existing database with date references and you have selected the wrong calendar setting, the program might report a variety of errors or other unexpected behaviors. For example, if you have checked the Hijri Calendar setting, Access will display a syntax error message if a report makes reference to Gregorian dates that are invalid as Hijri dates (for example, the date 12/31/99 will produce a syntax error because no Hijri month has 31 days).

To avoid problems of this sort, all date references in a database must be based on the same calendar.

Important  It is recommended that you choose the database calendar when you first create your database, and then never change it.

Other considerations when the database calendar is set to Hijri

• To ensure Hijri dates strings are evaluated correctly in expressions and Visual Basic for Applications statements, use the CDate function to evaluate the strings instead of declaring the strings as constants.

  For example, type CDate("1/25/20") instead of #1/25/20#.

  The CDate function will always return a value based on the active database calendar, whereas date constants are always evaluated by using the Gregorian calendar.

• For reliable behavior, enter and display dates in an unambiguous format. For example, dates in short date format might be misinterpreted in queries if the year or the day of the month are 12 or less (for example, 3/11/10). Dates in medium date format display only the first few characters of the month name, which can create ambiguity or an undesirable appearance. Use long date format whenever possible. You can alter the way a date is displayed in long format (for example, excluding the day of the month) by using the regional settings in Microsoft Windows Control Panel.
• Dates entered in the ValidationRule property of a Date/Time field in a table (in table Design view) must be Hijri. However, to have the ValidationRule date appear as a Hijri date in validation messages, the validation rule must use the CDate function (for example, 'CDate ("1/25/1420")'.
• Sample Access applications, such as the Northwind database, are not localized and expect the database calendar to be Gregorian. Because the sample applications contain hard-coded date constants that are not valid Hijri dates, running the sample applications with the database calendar set to Hijri is not recommended.
• All Hijri years will be displayed as four-digit year values (for example, 1420) unless the Format() function is explicitly used.
• The Visual Basic Date function, used to set the system date for your computer, will not accept Hijri dates. If the database calendar is set to Hijri, set the calendar to Gregorian before setting system date with the Date function.
• Dates in tables exported as text files are always stored as Gregorian values. If the database calendar is set to Hijri, automatic Hijri to Gregorian conversion is performed during the export process. Similarly, dates in tables imported from text files are assumed to be Gregorian dates and will be converted to Hijri values during the import process if the database calendar setting is Hijri.

The default Access sort order, General, handles sorting of right-to-left characters; that is, there are no separate sort orders for right-to-left languages. General sort order now includes right-to-left characters because characters are stored as Unicode values. The behavior of General sort order for right-to-left characters stored as Unicode values is identical to the behavior of right-to-left characters previously stored as Arabic or Hebrew code page values and sorted by using Arabic sort order and Hebrew sort order, respectively.

Right-to-left text is sorted along the following guidelines:

• Left-to-right text is always sorted ahead of right-to-left text
• Sort ignores kashidas and bidirectional control characters
• Characters with diacritics are clustered after other occurrences of the base character

Note  When opened or imported, previous-version databases that use a right-to-left sort order are saved with the Access General sort order.

Right-to-left enabled Access supports several code pages used in importing, saving, and exporting HTML Web pages. See the next topic About code page and text layout support for right-to-left HTML files for more information about supported code pages

A table or worksheet in Lotus, dBASE, Microsoft FoxPro, Paradox, or ODBC database format that requires code page or text layout conversion can still be imported into Access by saving the table or worksheet in text file format prior to importing it. The ability to save a table or worksheet in text file format is a standard feature of most database or spreadsheet products. When Access imports the text file, all field names and records from the original table or worksheet will be fully recreated in a new Access table.

To import, export, or link text files that are not recognized by Access, use ConvText.exe, a stand-alone text-file conversion utility that provides both logical and visual text layout options and an expanded list of supported bidirectional code pages. ConvText.exe is available on the Microsoft Office Web site and on the installation CDs for Microsoft Office language versions that offer right-to-left support.

Right-to-left enabled Access supports several code pages used in importing, saving, and exporting HTML Web pages.

Code page conversion of tables or worksheets with right-to-left characteristics is provided for HTML files stored in logical text layout and one of the following right-to-left code pages:

The following are some considerations to keep in mind:

• You can create custom menu bars in a right-to-left or left-to-right direction.
• The TransferText action allows you to choose code page format when importing, exporting, and linking files.
• Menu bars you create can be displayed with a left-to-right or right-to-left direction. For example, if oriented right-to-left, the menu bar will display with menu items starting on the right side of the menu bar and continuing to the left in a right-to-left reading order.
• The display direction of global and form menu bars is determined by the user-interface language.
• You can name menu items in right-to-left, left-to-right, or bidirectional text. An ampersand (&) can be added to a menu item name to designate a menu item access key. The ampersand applies to the next character in the name and causes the character to be underlined when the menu item is displayed. In right-to-left text, this is the character to the left of the ampersand; in left-to-right text, it's the character to the right of the ampersand.
• Macro names can be in right-to-left, left-to-right, or bidirectional text.
• The Macro window has a left-to-right layout regardless of the user-interface language.

Access supports these right-to-left characteristics in modules:

• You can view and edit Visual Basic for Applications statements containing right-to-left or bidirectional text.
• Statements are displayed left-aligned and in left-to-right reading order.
• You can use right-to-left, left-to-right, or bidirectional text in module names.

Visual Basic for Applications

All Microsoft Visual Basic for Applications procedures and properties that provide right-to-left functionality to Access are listed alphabetically in the following table.